Distributed computer platform with flexible configuration

ABSTRACT

Embodiments of the present invention provide a system and method of modeling a computer system. The computer system is modeled by a plurality of components and a plurality of interface enabling interactions between the components. A searchable tree data structure defining the components and the interactions between the components is generated and stored. The searchable tree data structure may be utilized to determine a status of a particular component. Based upon the status of the component, one or more interactions between the component and another may be enabled.

[0001] The present invention relates to a computer system, e.g. anetworked computer system.

[0002] In published patent application WO/0184313 (and/or correspondingUS 2002/0007468 A1), the applicant company has proposed a system andmethod for achieving high availability in a networked computer system.It has also proposed a system and method for usinghigh-availability-aware components to achieve high availability in anetworked computer system.

[0003] It has now been found of interest to model the platform and/orthe applications which run on it, totally or partially. This inventionoffers various aspects of such a modeling, which is applicableindependently of the high availability aspects. This invention alsooffers applications of such a modeling, as it will be seen hereinafter.

[0004] Generally, in one of its aspects, this invention applies to acomputer system, comprising components, and interfaces enablinginteractions between such components. The computer system comprises:

[0005] a repository, comprising a group of data representing a currentcondition of the components and interactions, at least some of the datacomprising an historic indication, with the historic indication being atleast one of a version and an update level, and

[0006] search code enabling such data to be searched for determining thestatus of a particular component in the computer system.

[0007] In another aspect, this invention offers a method of managing acomputer system, comprising the steps of:

[0008] a. defining entities in the computer system as components, andinteractions between such components,

[0009] b. storing in the computer system a group of data forming asearchable representation of the components and of their interactions.

[0010] This invention also encompasses the program product comprisingthe software code capable of building the repository as above defined,and, also an operating system, comprising such a program product.

[0011] Other alternative features and advantages of the invention willappear in the detailed description below and in the appended drawings,in which:

[0012]FIG. 1 is a tree diagram depicting an exemplary physical componenthierarchy among hardware components in a networked computer system;

[0013]FIG. 2 is a tree diagram depicting an exemplary software componenthierarchy among software components in a networked computer system;

[0014]FIG. 3 is a representational diagram of an exemplary componentthat may be used in an embodiment of the present invention;

[0015]FIG. 4 is a representational diagram of one embodiment ofdistributed system services that may be used in an embodiment of thepresent invention;

[0016]FIG. 5 illustratively shows software components, formingclient/server combinations;

[0017]FIG. 6 shows an exemplary organization of model data, in anembodiment of this invention;

[0018]FIG. 7 is a flow-chart of an exemplary version attribute checkingtool;

[0019]FIG. 8 shows an exemplary naming tree;

[0020]FIG. 9 is a block diagram of an embodiment of this invention, atthe design level;

[0021]FIG. 10 is a block diagram of an embodiment of this invention, atthe operational level;

[0022]FIG. 11 is a flow chart of an exemplary tool for checking theaccuracy of version value intervals;

[0023]FIG. 12 is a flow chart of an exemplary tool for checking versionconsistency;

[0024]FIG. 13 is a flow chart of an exemplary tool for checking aconfiguration update;

[0025]FIG. 14 is a “file-oriented” form of the flowchart of FIG. 13;

[0026]FIG. 15 is a flow chart of an exemplary platform update;

[0027]FIG. 16 is a flow chart of an exemplary tool for checking thecompatibility of an update set;

[0028]FIG. 17 diagrammatically shows a “software load life cycle”;

[0029]FIG. 18 is an exemplary block diagram showing how a given(hardware or software) component may interact with its surroundings, atthe design level;

[0030]FIG. 19 is an exemplary block diagram showing how a given(hardware or software) component may interact with its surroundings, atthe runtime level;

[0031]FIG. 20 is an exemplary flow chart showing how a component typeconfiguration MIB may be used when developing a component;

[0032]FIG. 21 is an exemplary diagram showing a platform updateoperation;

[0033]FIG. 22 is another exemplary diagram showing a platform updateoperation, in a different view;

[0034]FIG. 23 is an exemplary diagram showing the configuration of acomponent;

[0035]FIG. 24 is an exemplary diagram showing a software update;

[0036]FIG. 25 is an exemplary diagram showing a configuration update,made in response to a configuration update event;

[0037]FIG. 26 is an exemplary diagram showing a component, and itsinteractions with its surroundings; and

[0038]FIG. 27 is an exemplary diagram showing the operation of tworedundant components, and their interactions with the surroundings.

[0039] As they may be cited in this specification, Sun, SunMicrosystems, docs.sun.com, Answerbook, Answerbook2, Solaris, Java,EmbeddedJava, PersonalJava, JavaBeans, Java Naming and DirectoryInterface, JDBC, Enterprise JavaBeans (EJB), Jini, Sun SpontaneousManagement, Java 2 Enterprise Edition (J2EE), JavaServer Pages (JSP) andI-planet are trademarks of Sun Microsystems, Inc. SPARC is a trademarkof SPARC International, Inc.

[0040] A portion of the disclosure of this patent document containsmaterial which may be subject to copyright protection. The copyrightowner has no objection to the facsimile reproduction by anyone of thepatent document or the patent disclosure, as it appears in the Patentand Trademark Office patent file or records, but otherwise reserves allcopyright and/or author's rights whatsoever.

[0041] Additionally, the detailed description is supplemented with thefollowing Exhibits:

[0042] Exhibit Eh1 contains an exemplary Document Type Definition or DTDin XML;

[0043] Exhibit Eh2 comprises explanations on XML, and tables summarizingelements of the DTD of Exhibit Eh1;

[0044] Exhibit Eh3 is a description of the elements in the exemplary DTDof Exhibit Eh1;

[0045] Exhibit Eh4 shows exemplary CGHA-ML code or “CGHA-MLdefinitions”;

[0046] Exhibit Eh5 comprises tables for use in connection with ExhibitEh4;

[0047] Exhibit Eh6 shows exemplary tables of mapping from CGHA-ML;

[0048] Exhibit Eh7 shows exemplary LDAP configuration objects;

[0049] Exhibit Eh8 contains illustrative tables;

[0050] Exhibit Eh9 contains an exemplary LDAP object, i.e. a componenttype configuration MIB.

[0051] In the foregoing description, references to the Exhibits are maybe made directly by the Exhibit or Exhibit section identifier: forexample, Eh7-O1 would refer to section O1 in Exhibit Eh7 (the prefixdesignating the Exhibit may be omitted if there is no ambiguity). TheExhibits are placed apart for the purpose of clarifying the detaileddescription, and of enabling easier reference. They nevertheless form anintegral part of the description of the present invention. This appliesto the drawings as well.

[0052] Now, making reference to software entities imposes certainconventions in notation. For example, in the detailed description,Italics (or the quote sign “) may be used when deemed necessary forclarity. However, in code examples:

[0053] quote signs are used only when required in accordance with therules of writing code, i.e. for string values.

[0054] an expression framed with square brackets, e.g. [property=value]*is optional and may be repeated if followed by *;

[0055] a name followed with [ ] indicates an array.

[0056] Also, <version>may be used to designate a value for the entitynamed “version” (or version).

[0057] The reader is assumed to be familiar with object orientedprogramming in general, more specifically with Java. Details may befound at http://docs.sun.com. and http://Java.sun.com and/or in thecorresponding printed documentation, e.g. “The Java LanguageSpecification”, J. GOSLING, Bill JOY, Guy STEELE, Addison Wesley, 1996,ISBN 0-201-63451-1. Other printed documentation is currently availableat:

[0058] http://www1.fatbrain.com/documentation/sun.

[0059] The reader is also assumed to be familiar with the eXtendedMarkup Language (XML) specification, available from W3C athttp://www.w3.org/TR, and/or from the booklet “XML Pocket Reference”,Robert ECKSTEIN, O'REILLY, U.S.A, October 1999.

[0060] The reader is further assumed to be able to map from a model inUML to a programming language such as Java or C++, and to be familiarwith client-server applications written in C. The Unified ModelingLanguage, or UML, is defined inter alia in Appendix D of the CommonInformation Model (CIM) specification, available on the web site of theDistributed Management Task Force (DMTF), http://www.dtmf.org/, or inthe corresponding printed documentation.

[0061] The reader is again assumed to be familiar with LDAP (LightweightDirectory Access Protocol). A detailed description of LDAP may be foundat www.open1dap.org/devel/admin/, and in the corresponding printeddocumentation.

[0062] A number of concepts described in the above cited WO/0184313 maybe of interest in understanding the context and principles of thisinvention. Accordingly, the descriptive portion of WO/0184313 and/or US2002/0007468 A1 is incorporated by reference in this application.Alternatively, reservation is made for the inclusion of their FIGS. 1through 11, together with their description [i.e. paragraphs [0037]through [0174] of US 2002/0007468 A1 or the corresponding text inWO/0184313), as an additional attachment to this application.

[0063] The above described system may be used in a variety ofapplications. One of these is High Availability Platforms (HAplatforms), as used in real time non stop computer networks. In thefield of telecommunications, the applicant company has such a project,named Carrier-Grade High Availability Software Platform (CGHA SoftwarePlatform).

[0064]FIG. 1, FIG. 2, FIG. 3 and FIG. 4 here correspond to FIG. 3, FIG.4, FIG. 6 and FIG. 9, respectively, in WO/0184313, with the same drawinglabels, and will be shortly described here as an exemplary computerplatform. Further details may be found in WO/0184313 and/or US2002/0007468 A1.

[0065]FIG. 1 is a tree diagram depicting an exemplary physical componenthierarchy (or physical containment relationships) among hardwarecomponents in a networked computer system. A network element 300includes shelves 301 and 302. The shelf 301 further includes non hostsystem processors or NHSPs 303 and 307, host system processors or HSPs305 and 306, and a hot swap controller HSC 304. The components thatcomprise the shelf 301 may themselves contain additional components. Forexample, the HSC 304 includes fans 308 and power supplies 309.

[0066]FIG. 2 is a tree diagram illustrating exemplary non-physicalcontainment relationships or software component hierarchy among softwarecomponents in a networked computer system. A network element 400includes a node-1 401, node-2 402, and node-3 403. Each node may containadditional components. For example, the node-1 401 includes an operatingsystem 404, Asynchronous Transfer Mode (“ATM”) stack 405, ATM driver406, ethernet driver 407, and management applications 408.

[0067] Components may be viewed as a fundamental unit of encapsulation,deployment, and manageability. When new applications and devices areadded to a networked computer system, they are typically added as newcomponents.

[0068] To prevent service outages during normal operation, componentsmay accept dynamic changes in their configuration. It is common for theconfiguration of network-based applications to change during normaloperation. To prevent frequent outages due to these configurationchanges, components may be held responsible for recognizing that theirconfiguration has changed and taking this change into account byoperating based on the new configuration.

[0069] As shown in FIG. 3, a component 601 might contain physicaldevices and their drivers 600A, applications 600B, diagnosticapplications 600D, applications for conducting audits 600C, and erroranalysis applications 600E.

[0070] By providing standard class-interfaces through which componentsinteract with management agents and other applications, components mayallow developers greater freedom in structuring and implementingcomponents. In FIG. 3, a component manager 601 may function as aninterface to a management agent (“MA”) 602 and a component role andinstance manager (“CRIM”) 603. The component 600 may also interface witha component error correlator (“CEC”) 605 and clients 604.

[0071] If newly-supplied components fully support all of the interfacesassociated with their class and/or sub-class, they would automaticallybe manageable within various management contexts.

[0072] In an embodiment, distributed system services (“DSS”) may beused-the DSS may include a collection of location-independent mechanismsthat enable applications to interact with one another. The DSS mayenable applications to interact with one another without knowing wherethey are running, or where the other applications with which they arecommunicating are running. Using the DSS, all applications may see thesame messaging, event, and configuration services, independently ofwhich node they happen to be running on. In other words, the DSS mayallow applications to communicate regardless of their relativelocations.

[0073] Application services may also interact with their clients throughthe DSS, allowing them to migrate from one node to another withoutaffecting their clients. The DSS may also facilitate load-sharing andsystem expansion by allowing work to be distributed among multipleprocessor nodes.

[0074] As an Example, FIG. 4 is a representational diagram of onepreferred embodiment of DSS. In FIG. 4, a DSS 900 provides at leastseven types of services and/or mechanisms—a cluster naming service(“CNS”) 901, cluster event service (“CES”) 902, cluster configurationrepository (“CCR”) 903, cluster replicated checkpoints (“CRC”) 904,reliable remote procedure calls (“RRPC”) 906, asynchronous messages(“AM”) 905, and reliable transport 907.

[0075] The RRPC 906 may provide a mechanism for basic intra-cluster orintra-system communications. Using this mechanism, for example, a clientmay issue a request to any server in the system without regard to theirrespective locations and await a response. The RRPC 906 may be suitablefor services that require positive acknowledgments for robustness,require distinct requests to be serialized, or offer an automatic retryin case of a server failure.

[0076] The AM 905 may also provide a mechanism for basic intra-clusteror intra-system communications. The AM 905 may require responses and maybe suited for services that require minimum latency and overhead, do notrequire explicit acknowledgment or serialization, or can operateproperly despite occasional silent failures.

[0077] The RRPC 906 and AM 905 may also send calls and/or messages fromexactly one sender to exactly one receiver over a pre-arrangedpoint-to-point communication channel.

[0078] The CNS 901 may be used to provide a cluster-wide, highlyavailable naming service. Servers may register communication handles(and other things) under well-known names in a hierarchically structuredname space provided by the CNS 901. Clients may look up the names forservices they want, and obtain communication handles (or other objectsto support the exchange of services). Handles for both the RRPC 906 andAM 905 may also be registered and obtained from the CNS 901.

[0079] The CES 902 may automatically distribute events from a publisherto all processes in a cluster that have subscribed to that type of theevent. Using the CES 902, a publisher may not need to establish anexplicit channel with all possible subscribers. Similarly, subscribersmay not need to establish an explicit channel with a publisher.

[0080] It has now been found of high interest to model such a platformand/or the applications which run on it, totally or partially. Thisinvention offers various aspects of such a modeling, including a new,polyvalent, software language, which may not only be used fortheoretical modeling as such, as other modeling languages do, but alsois “operational”, i.e. may be accessed by software processing tools,like generators or compilers, other than user interface for edition ofthe model. Such an Operational Modeling Software Language is hereinaftergenerically noted in short “OMSL”.

[0081] In WO 01/44934, the applicant company has described thepreparation of a software configuration, using an XML type programminglanguage. In one of its aspects, the present patent specification nowcomes to propose a concept for at least partially modeling a platformand/or the application running on it. “At least partially modeling”indicates that the modeling may be restricted to what is required tomaintain the platform in operation.

[0082] Broadly, the OMSL language being proposed may provide a singledescription of the interfaces, management information and deploymentconfiguration for application software, system software and/or hardware.This description may also be used by middleware. “Middleware” hererefers to various software codes (e.g. the so-called “glue code”)existing between the operating system and the application software.

[0083]FIG. 5 illustratively shows seven software components COMP1through COMP7, which are servers or clients (the version aspects of FIG.5 will be considered later). Server COMP2 provides interface I1 which isused by both clients COMP1 and COMP2. Server COMP6 provides bothinterface I2 which is used by client COMP7, and interface I1, used byCOMP1. Client COMP5 uses both interface I1, providedby server COMP4, andinterface I2, provided by server COMP6. The case of a component beingboth client and server is a simple extension of the scheme.

[0084] The model data may be organized as shown in FIG. 6, which will bedescribed first, to help in understanding the description of the OMSLlanguage.

[0085] The Interface model MO1 comprises sets of interface data MO1x(e.g. files), representing interfaces like those of FIG. 5. Thecomponent model MO2 comprises sets of component data MO2x, based oninterface data MO1x. The software load model MO3 comprises sets ofsoftware load data MO3x, defining a given arrangement of components andof their interfaces in a platform. The configuration update model MO4comprises sets of configuration data MO4x, which may be viewed as“settings” as required by the platform when a corresponding givenarrangement of components is in operation. Finally, the platform updatemodel MO5 comprises sets of platform update data MO5x, each of whichdefines possible evolutions of the platform, with reference to a“current load” MO5CL (which may be viewed as separate from model MO5, orincluded in it).

[0086] As shown in FIG. 6, up to five models may be supported. This isexemplary only, and the invention may apply as well where only some ofthese models would be used, and/or some are mixed together.

[0087] In certain flowchart drawing boxes, the identifier of therelevant model is shown in the upper leftmost corner of the box.

[0088] The OMSL language may be based on eXtended Markup Language (XML),or on a similar modeling language.

[0089] Exhibit Eh1 shows an exemplary document type definition (DTD). Asknown, the DTDs are one of the current possibilities offered by XML fordefining the language rules, and many tools exist to exploit them.However, alternative possibilities offered by XML, like XML schemas, maybe used as well. Also, other language rule definitions may be used whenusing modeling languages other than XML, which may further be convertedinto XML, if desired. For example, UML may be converted into XML usingXMI.

[0090] When reading the DTD, attention should be paid to the word type,which may have different meanings:

[0091] the type e.g. of a constant, as usual in computer software,

[0092] an extended meaning, where type is associated with an identifier,and refers to the nature of the entity to be represented with that name.The type identifier itself is thus a name, but that name further impliesconsequences as to the nature of the entity being named. In other words,a type defines some kind of specimen of an entity. Usually, a typeidentifier will have to follow certain rules, e.g. those related toversioning, to be described. The OMSL language defined by the DTD ofExhibit Eh1 has been termed “CGHA Markup Language (CGHA-ML)”, since itintends to serve in an HA or CGHA platform. Thus, with a view tofacilitate understanding, reference may be made here to the system andto its constituents with the label or prefix “CGHA”. It must be clearlyunderstood, however, that “CGHA” or “CGHA-ML” is used here as aconvenient label, and that its use does not involve any intendedlimitation to a CGHA platform, and/or to telecommunication applications,and/or to the exemplary embodiment of CGHA-ML being described.

[0093] Turning to the Document Type Definition or DTD shown in ExhibitEh1, those skilled in the art will appreciate that such a DTD defines aset of tools for modeling various platforms, i.e. hardware and/orsoftware systems. For those being not familiar with XML, Exhibit Eh2recalls the main concepts of XML, and has tables describing mostelements of the DTD of Exhibit Eh1 in natural language.

[0094] Exhibit Eh3 describes the syntax and semantics of how toconstruct the above models when using e.g. the exemplary DTD of ExhibitEh1.

[0095] All of the above models may support versioning. In the example,the version attribute is a positive integer. Other “incrementable”definitions may be used as well, with or without letters and/orseparators.

[0096] When in use, versioning may be implemented e.g. as follows: afile defining an entity called <Entityname> may be named:<Entityname>.xml, if the entity has no version, or<Entityname>.<version>.xml, if the entity is versioned, with <version>being e.g. 1, 2, 3.

[0097] In the exemplary Component Model, at least one ELEMENT hasminVersion and maxVersion attributes. As shown in Table Eh2-1, theexample shows in fact two such ELEMENTs: cgha:use, and cgha.provide,which may be used to offer two different functionalities:

[0098] the cgha:use element (C2) may be used to declare the versions ofan interface that are used by a component, considered as a client.

[0099] the cgha:provide element (C5) may be used to declare the versionsof an interface that are provided through a SAP, by a componentconsidered as a server.

[0100] In each case:

[0101] minVersion specifies the oldest version of the interface that isused/provided, i.e. the version with the lowest version number.

[0102] max Version specifies the most recent version of the interfacethat is used/provided, i.e. the version with the highest version number.The value of this attribute must be greater than or equal to the valueof the minVersion attribute (for the same entity created from use orprovide).

[0103] It will be appreciated that a number of objects or ELEMENTs inthe DTD admit a “version” attribute, which may be required or optional.This is summarized in Table Eh2-2. The fact that version is optional incertain case is an implementation choice, which may reflect the factthat certain ELEMENTS will rarely change. In fact all ELEMENTS might beversioned.

[0104] In the exemplary embodiment, versioning is mandatory:

[0105] in the interface model, for interfaces and object references, andalso for event and the publish aspects, if implemented,

[0106] in the other models, for the components, the platform update,configuration update and software load models.

[0107] Each versioned “ELEMENT” may be used as an attribute in anotherELEMENT, using the cgha:attribute.

[0108] The flow-chart of FIG. 7 shows an example of how versionattribute checking (4500) may be made, when creating an entity, e.g. bya dedicated tool which may be incorporated in an OMSL compiler. Theentity derives from an ELEMENT generically noted cgha:xxx, where xxx maybe one of the elements of the DTD. The type identifier or entity name is“entName” (4502) Operation 4504 determines whether “entName” alreadyexists, or not. This may use the naming tree to be described inconnection with FIG. 8.

[0109] In the case of a new name, if version is supported by cgha:xxx(4510) and mandatory, i.e. “required” (4512), operation 4514 verifiesthat version 1 is created (starting at any integer version might also beallowed). If version is not supported, no version number is allowed(4518). If version is supported, but not required, anything is possible(4516).

[0110] In the case of an existing name, if version is not supported bycgha:xxx (4520), it is not allowed (4528), like for 4518. If it isallowed and required (4522), a last version is sought (4526), and theentName should be supplemented (4526) with a version indicationincremented by 1 (or any version number representing a non existingversion, preferably a higher version). Then, at least for certainentities, compatibility between version may be checked, optionally(4527). If version is supported, but not required, operation 4524determines whether a last version exists for entName; if so, therequired path of operations 4526 and 4527 is taken, otherwise the“unversioned” operation 4528 applies.

[0111] At 4527, checking compatibility between versions may beimplemented, e.g. for the following CGHA-ML entities along the followingexemplary rules:

[0112] interface:

[0113] Two versions of the same interface must not have an operation, anattribute or a constant with the same name and a different signature.The signature of an operation consists of the number and types of itsarguments, its return type and its declared exceptions. The signature ofan attribute or a constant is its type (plus its version, ifimplemented). Note that two attributes with the same name must have thesame type. This may be verified by the OMSL compiler.

[0114] For a number of other entities whose versioning is optional (e.g.structure, enumeration), there may be no need to mandate anycompatibility between two versions of such an entity.

[0115] Whatever its internal operation is, a software entity orcomponent is known of other software entities essentially by what itexchanges with them. This may be broadly termed its “interfaces”;however, in practice, a difference is made between interfaces as such,examples of which have been discussed with reference to FIG. 5, andother software “beings”, like the exceptions and events.

[0116] First, by using such an OMSL, it is possible to define acollection of interfaces, attributes (in the target software platform,not XML attributes), structure members, parameters, objects or contexts.Each of these can be defined by a group of data having a type, likesimple type or structure. Examples of such groups of data are:

[0117] a map, which is an unordered set of pairs (key, value), where thekey is an arbitrary string and the value is of a base type. All valueshave the same base type in a given map. A map is specified by settingthe map attribute to “yes”.

[0118] an array, which is an ordered list of elements of the same basetype, indexed by integers. An array is specified by setting the arrayattribute to “yes”.

[0119] The interface model makes it possible to describe sophisticatedparameters, as they exist in the interactions of components within acomputer platform, and thus to define models of that platform. Themodels may be represented by OSML files, which are XML files in theexample. Other representations may be used as well, e.g. the LDAPrepresentation to be described. Thus, OMSL files (files in the OSMLlanguage) may be constructed by platform architects, and stored in arepository (hereinafter called OSML or XML repository).

[0120] Except where versioning and update level applies, two differentitems should have different names (or identifiers). To facilitate this,the repository may be organized as a hierarchical tree, which reflectsthe structure of the OMSL package hierarchy, also in connection with thenaming of OMSL packages, if desired.

[0121] An exemplary organization of the OMSL Repository on a customerplatform will now be described with reference to FIG. 8. (Note the OMSLis CGHA-ML in the drawings.)

[0122] After a main “root” node N0, there are three sub-trees with theirroots in N10, N20 and N30. Then:

[0123] the subtree stemming from nexus N110 (com/sun) may be arrangedwith a sub-nexus N1100 (cgha) forming a path to contain predefined OMSLfiles describing types (interface model) and components (componentmodel). It may be arranged with sub-nexus to distinguish standard OSMLSoftware Platform types (N1101) and internal system components (N1102and N1103). This may be called the “system repository tree”.

[0124] the tree stemming from root N120 (com/telco) containscustomer-specific OMSL files describing the customer platform andapplications (“telco” is used here as a generic name for a customerorganization). Its nexus N1201, N1202 and N1203 may follow anorganization similar to those of the system repository tree (N1101,N1102 and N1103). However, other organizations may be chosen as well.For example, the customer-specific portion of the repository could benamed f/telco, or it could be located elsewhere in the file system.

[0125] the tree with root N20 (updates in the example) may contain OMSLfiles describing successive platform updates of the customerapplication. These files follow the software load model, theconfiguration update model or the platform update model.

[0126] finally, root N30 (cghaml.dtd) contains the unmodifiable file orfiles which define the OMSL syntax, e.g. the Document Type Definition orDTD.

[0127] In the exemplary system Repository tree (cor/sun sub-tree), onlyfinal directories, e.g. N1101, contain actual OMSL files (leaves of thetree). The directory N110 contains standard types and system components:

[0128] directory N1101 contains common interfaces and standard typesused in the Software Platform. These “leaf” files follow the OMSLinterface model. Subdirectories of N1101 may be used to receive filesdescribing types specific to system components, for example ccm(N11031), cec (N11032), and crim (N11033).

[0129] directory N1102 contains files defining hardware components. Allfiles related to a hardware component may be located in a subdirectory,which contains the definition of the component as well as optional,specific component types and interfaces. For example, the followinghardware component subdirectories may be defined: netrat1 (N11021),network element (N11022), shelf (N11023).

[0130] The platform software N1103 directory contains files definingsystem components of the Software Platform. All files related to asystem component may be located in a corresponding subdirectory. Thissubdirectory contains a file defining the component (component model).It may also contain files defining types and interfaces specific to thecomponent, using the interface type model. For example, the followingsystem components may be defined: bootserver, ccm, cec, ces, cet, chm,cls, cmm, crcs, crim, csum, ma, oscm, slim, sltm.

[0131] Turning now to FIG. 9, a repository 2010 contains the modelfiles, which may comprise the DTD 2011, predefined files 2012, andcustom files 2013. The custom files may be prepared using an XML editor2020, with a user interface 2021, e.g. the “XML mode” of the GNU “emacs”editor of the GNU.

[0132] The rest of FIG. 9, i.e. the frame in dashed line 2030, may becalled OMSL compiler, or, in short, compiler. It may include XMLlanguage editing tools, which may use a catalog file, e.g. an XML parser2031, with a semantic analyzer 2032 (and, optionally, a syntacticanalyzer, not shown). Then, one or more generators 2034 may be used tobuild files 2035 in other languages and/or formats. Three differentlanguages lang.1, lang.2 and lang.3 are shown, by way of illustrationonly. In practice, the languages may range from Java and C/RPC to LDAP,HTML, while using corresponding mappings as necessary. Generators 2034may also be used for other purposes, e.g. with the software loadmapping.

[0133] Reference is now made to FIG. 10, which shows a system embodyingseveral other inventive aspects.

[0134] The repository 1510 may comprise various software packages (XMLfiles and package files), amongst the following: platform update,configuration update, software load, applications, middleware, Operatingsystem, hardware, and types. These may be checked at 2300, e.g. asdescribed with reference to FIG. 9. At 2320, software factory tools maybe used to build:

[0135] component framework code 2340, which may comprise e.g. clientstubs, service skeleton code, and management skeletons code, for examplein C or C++;

[0136] one or more software load images 1570,

[0137] LDAP data 2400, e.g. for use when the target system willinternally need information about its own status and constitution, e.g.at runtime, and

[0138] a Management agent framework 2500, e.g. using Mbeans, and theapplicant company's JDMK, i.e. java.

[0139] The models of FIG. 6 will now be reviewed in more detail, withreference to the corresponding sections of the exemplary CGHA-ML inExhibit Eh3, and to the example of FIG. 8.

[0140] The interface model MO1 (Eh3.2) basically describes interfaces,and may also involve e.g. events, and/or exceptions. A given set ofmodeled interfaces will comprise the the interfaces that may exist in(be provided or used by) components of the platform, or a given part ofit. Each interface defines the services that will be provided by, orsupplied to, a component (subject to the capability of the component tohave that interface).

[0141] The interface model MO1 (used e.g. in N1101) may basicallysupport the specification of Interfaces. It may also support Events.

[0142] In the embodiment, other auxiliary entities are also put in theinterface model MO1: Exceptions, Structures, Object references,References, Enumerations.

[0143] Certain items of MO1 may have attributes, e.g. configurationattributes, for which the given set of modeled interfaces may definedefault values.

[0144] Typically, a file might contain one interface, together with therelated exceptions and the structures necessary to define thisinterface. They may be grouped semantically, so that, for example,everything related to one call mechanism will be grouped in one file.However, various interface items may be mixed in the same file.

[0145] The interface model MO1 comprises the same level of functionalityas CORBA IDL or Java RMI, with support for inheritance and exceptions.It has new features to cope with versioning, synchronous/asynchronousmode of communication and configuration.

[0146] Now, the component model MO2 (Eh3.3) represents components, usingthe above mentioned interface items. A component may be represented by a“component type”, together with the interfaces it provides and theinterfaces it uses.

[0147] The representation of components may use a tree structure, e.g. ahierarchical naming tree where each leaf is an object that implements aninterface type. Furthermore, one may associate an object with each nodeof the naming tree. This is termed a Management Information Base, orMIB.

[0148] A dedicated MIB may handle the configuration associated with thecomponent type (e.g. a network element or cluster). A MIB is associatedto its container, which may be e.g. a SAP (Service Access Point), acomponent type, or a cluster. In the MIB, it is possible to override thedefault value of the configuration, coming from the interface model.

[0149] SAPs are used to specify particular aspects of a component, forexample management, high availability or service. Each SAP provides aset of interfaces and an optional MIB.

[0150] A given set MO2x of modeled components may have the form ofcomponent model files, which may be located in the directories stemmingfrom N1102, N1103, N1202, N1203. In a simple embodiment, an XML file maycontain only one component.

[0151] In more general terms, the component model defines componenttypes which may be used on a cluster (whether hardware or software). Inthe case of software, component instances define the component typeswhich are presently available; component assignments define if and howthe component instances are assigned roles dynamically in the SoftwarePlatform (this may be also applied to controllable aspects of hardware).

[0152] In the example, the versioning follows simple basic rules:

[0153] a given entity myEntity created from use (client) or provide(server) must have two version values for its minVersion and max Versionattributes, respectively;

[0154] it is not entitled to offer an interface (or other versioneditem) whose version value is denoted <version> unless two conditions aremet:

[0155] <version> is equal to or greater than the minVersion value ofmyEntity

[0156] <version> is equal to or lower than the max Version value ofmyEntity

[0157] If desired, the accuracy of the [minVersion, maxVersion]intervals of the use and provide OMSL elements may be checked, e.g. asshown in the flow chart of FIG. 11. For each component Ci in thecomponent model (5010), operation 5012 gets the interfaces used by Ci,and, for each such interface gets the [minVersion, maxVersion] intervalWUi for use. Operation 5014 checks that the Interface model indeed hasan interface for each version within interval Wui. Operation 5018indicates that the same is done with [minVersion, maxVersion] intervalWPi for provide.

[0158] Other mechanisms may be constructed, using the version, on theone hand, and the [minVersion, maxVersion] interval, on another hand,based on similar principles.

[0159] The software load model MO3 (Eh3.4) specifies the software loadsthat are deployed on a given portion of the software platform, forexample a Network Element, hereinafter termed a cluster by way ofsimplification. A software load represents a set of components (softwareand hardware). Along the exemplary embodiment, multiple versions of thesame component are not allowed in a given software load (this wouldinduce a more complicated processing).

[0160] In a given software load:

[0161] Each component is represented by:

[0162] its definition in the OMSL model, in the example a component typeconfiguration MIB, an instance MIB, and an assignment MIB,

[0163] a list of software packages, and

[0164] a descriptor of its target localization.

[0165] The configuration associated with the Network Element or cluster(hosting the components) is handled through a dedicated MIB, calledcluster configuration MIB.

[0166] The flow chart of FIG. 12 shows how version consistency may bechecked, e.g. within a given software load MO3x. Starting from a list ofcoexisting components (5000) in the software load MO3x, the componentmodel is used (5002) to build groups each of which may be viewed as aclient component Ci using Interface Ik provided by a server componentCj. Operation 5004 gets the [minVersion, maxVersion] interval Wi of Cifor Ik as “use”, and the [minVersion, maxVersion] interval Wj of Cj forIk as “provide”. The components can cooperate if the intersection of Wiand Wj is not nil, as checked by operation 5008.

[0167] A software load defines ingredients of a software platform. Agiven condition of the settings in a software platform is termed a“configuration”. The interface model MO1 and the component model MO2define two levels of default configuration settings. However, furthersettings may be made at the time the software load occurs.

[0168] Thus, the configuration update model MO4 (Eh3.5) defines theconfiguration of a given software load (“configuration load”), and anymodifications being made to that configuration. When initially loaded, aconfiguration is initialized, and then it may be updated.

[0169] Each configuration load may be seen as applying to a specificsoftware load. A given configuration load specifies the configuration ofall the components of the software load it aims at. Configuration valuesare applied in terms of type, instance and assignment, and also theconfiguration of the Network Element, including deployment descriptors,redundancy schema and component relationships (to the extentapplicable).

[0170] The configuration load section of the configuration update modelallows the initialization of a n-uplet of items, which, in the example,is a quadruplet: a cluster configuration, a component typeconfiguration, a component instance configuration and a componentassignment configuration. This implies that each component instance andcomponent assignment should be named in a unique fashion, in the abovedescribed naming tree.

[0171] The Configuration update model basically gives values tovariables (in the broadest meaning of the word variable); this has theform Vi=Xi ,for a given version, as shown in operation 5030 of FIG. 13.The Software load model is then accessed to know the component Ci beingconcerned by variable Vi (5032). The component model in turn indicateswhich MIB is concerned, and hence, which interface Ii is concerned(5034). And the interface model indicates the type of variable Vi(5036). An error is generated (5038) if any of the above level failed. Adifferent error is generated (5040) if Variable Vi was found final inany of these levels (except 5030). Finally, Vi=Xi is accepted if thetype of Vi, as found in the interface model, matches the type of Xi, asdefined at 5030.

[0172]FIG. 14 is a “file-oriented” form of the flowchart of FIG. 13.

[0173] The platform update model MO5 (Eh3.6) provides the specificationof a platform update. A platform update may be processed by the softwarefactory tools as shown in FIG. 15. It may comprise (5050) a “currentload”, which corresponds to the software load that is currently deployedon the Network Element, and its associated configuration. It may alsocomprise a list of configuration updates (from zero to N in number),and, optionally, a new software load, if any, that may be loaded on theNetwork Element in substitution of the current load and the associatedconfiguration.

[0174] The simplest role of the platform update model MO5 is to changethe configuration. First, all files involved in the update (andincluding configuration statements, in the form Vi=Xi) are compared(5052) with the corresponding files in the current load. If they arecompatible (5054, to be developed), the generation of a new current loadis allowed (5056). The new current load may be obtained by simplyapplying the configuration values being modified, as they were found atoperation 5052. The other configuration values are kept. Then, updatedconfiguration data are generated (5058).

[0175]FIG. 16 shows an exemplary way of checking the compatibility of anupdate set MO5x at operation 5054. Operation 50541 builds the list ofMIBs (MIBk) being involved in the update (the current load is assumed tohave been checked previously in a similar fashion, and to be correct).Operation 50543 accesses the files comprising those MIBs and thecorresponding components. Operation 50545 builds the list of allvariables to be configured for these. Operation 50547 checks that allthese variables are effectively given configuration values in theintended update (or in the current load).

[0176] Thus, a Platform Update Model may provide support:

[0177] for controlled and deterministic configuration updates to thecurrent software load running on the Network Element.

[0178] for upgrading the software running on the Network Element fromone release to a different release.

[0179] In other words, the Platform Update Model defines the SoftwareLoad and the Configuration Updates that are applied on a NetworkElement. In a configuration quadruplet (cluster, type, instance andassignment), each entity may have an associated update level. Thus,modification of the configuration is made possible without having tobuild a new Software Load.

[0180] The Software Factory tools 2030 may be used for managing thisnotion of update level. The update level is incremented (or otherwisedifferentiated) after the update has been checked and authorized. Theresulting configuration information may thereafter be provided to eachrunning component instance being “re-configured”.

[0181] Let entity be an item in the above mentioned quadruplet: clusterconfiguration, component type configuration, component instanceconfiguration and component assignment configuration. The configurationof such an item of a component is defined by:

[0182] its name <entityName>

[0183] its version, e.g. 2, and

[0184] its update level, e.g. 3.

[0185] The version is known at compilation time. The name is definedwhen the component entity is created. Conversely, such an entity may beinformed that its configuration has changed in an asynchronous fashionby an event, which may indicate the most recent update level. Inresponse, the entity will change its configuration, e.g. by re-booting,which forces it to reacquire its configuration data; “softer”reconfiguration processes may also be applied, subject to adequatelydetermining the status of the relevant portion of the platform.

[0186] To check the consistency of a software load and/or aconfiguration update in respect of what has been deployed on a NetworkElement, and to generate the appropriate update levels, the PlatformUpdate Model supports the definition of the current load.

[0187] A current load defines the components that have been deployed ona Network Element, defining for each component its type, its version,its instances and its assignments with the associated update levels andconfiguration. For the cluster, the current load defines its version,its update level and its configuration.

[0188] The Software Factory tools generate for each Platform Update theresulting state of the Network Element, using the cgha:currentLoadelement. This resulting state should be used as the current load inorder to define the next platform update of the Network Element.

[0189] Files containing a software load, a configuration update and/or aplatform update may be located in an updates subtree (N20). Each fileshould contain only one definition, named <definitionname>, which can bea software load, a platform update or a configuration update.

[0190] Now, rules and guidelines may be established to govern how aplatform and its components will be defined in the OMSL language. Thisconcerns both the organization of the files and their actual content.The rules and guidelines may have the following aspects:

[0191] the organization of the repository 1520 and the rules to beenforced when naming the software and/or hardware entities.

[0192] the rules that must be followed when defining a component.

[0193] Further rules that should be followed when defining a cluster maybe added, to correctly feature the hardware, and its redundancyfeatures.

[0194] OMSL models may be used as such, when conceiving an application(part or all of a system). They may also be mapped to programminglanguages, e.g. C or Java. This allows to link an application to othercomponents and to the Software Platform, and/or to provide remotemanageability of the platform.

[0195] Tables Eh6-1, Eh6-2 and Eh6-3 in Exhibit Eh6 show examples ofmappings to Java, C/RPC, and LDAP, respectively. Mapping from the OMSLto Java and/or C/RPC may be considered similar to mapping from othermodeling languages to Java and/or C/RPC, and therefore will not bedescribed in further detail. By contrast, mapping to LDAP will bedescribed in more detail hereinafter.

[0196] It will now be appreciated that the OMSL language has followingcapabilities, which, of course, may be used only partially:

[0197] establish a formalized description of a Software Platform(“information model”). In fact, the OMSL language may be used to modelnot only the applications that run on the HA Software Platform, but alsothe constituent entities of the platform itself (hardware, operatingsystem and/or middleware).

[0198] use of various user-oriented tools, e.g. validation tools, whenestablishing that formalized description.

[0199] possibility to build a set of specifications and tools to assistdevelopers with the design of components.

[0200] the formalized description in turn may be used by various“operational” tools, for example when developing components or whenconstructing software loads, and their configuration. This may go up tothe deployment of the components and of the platform on which they run.

[0201] The above defined models apply within what may be called a“software load life cycle”. This concept will now be illustrated withreference to FIG. 17. The notations used in FIG. 17, e.g. to the extentthey refer to an XML embodiment of this invention, are purely exemplary.In the tree hierarchy, the top level is “platform update” (N20, FIG. 8),which comprises a software load and a configuration.

[0202]FIG. 17 shows:

[0203] a package repository 1500, which may store in any appropriatedata format, e.g. a file system, the software code to be used inconnection with a particular platform, both at the hardware level, e.g.drivers, and at the software level, e.g. application programs.Middleware may also be included, as desired.

[0204] an OMSL repository, e.g. an XML repository, 1520, which may storein any appropriate data format, e.g. a file system, sets of the modeldata to be used, in the OMSL language.

[0205] Thus, a typical software load life cycle may involve:

[0206] the installation of one or more components 1530, 1531, 1532 ,which may use both repositories 1500 and 1520;

[0207] the definition of a software load 1540; this may use modelrepository 1520 only; and produces a representation of the softwareload, e.g. a softwareLoad.version.xml file;

[0208] the processing of the software load 1550 may involve a tool,named e.g. ml2swload, which uses that representation, in connection withboth repositories 1500 and 1520, to generate a corresponding list ofpackages 1552, named e.g. softwareLoad.version.pkgs.

[0209] the final software load build 1600, which converts the set ofpackages into a SoftwareLoad image 1570. The SoftwareLoad image 1570comprises data loadable in memory for operating a computer system, e.g.1590. This uses a Software Load Build Tool also denoted SLBT.

[0210]FIG. 17 is made in the form of interconnected blocks, for moreclearly showing the interactions between its elements. It will beappreciated that it may also be viewed as a flow chart, havingoperations 1530 through 1570. The separation in a plurality of levels ofoperations is purely illustrative. For example, operations 1550 through1570 might be considered as a single level of operations as well.

[0211] The Component Definition Rules will now be considered.

[0212] To begin with, FIG. 18 shows how a given (hardware or software)component 2100 is seen by its surroundings. It has a variety ofcomponent-to-component interfaces I210x with other components 210x. (thex reflects the fact the other components are plural). It also has acomponent-to-framework interface I2120 with the framework 2120.

[0213] The framework 2120 may comprises e.g. the following runtimetools:

[0214] the Component Role Instance Manager (CRIM) 2121, which definesthe instances and assignments of components,

[0215] the Management Agent (MA) 2122, which may be used to managesoftware,

[0216] the Component Executor and Terminator (CET) 2123, in charge ofhaving components being put in execution, or, on the contrary,terminated.

[0217] Additionally, the component may be associated (L2130) with acomponent configuration element 2130. Also, the framework 2120 may beassociated (L2140) with a cluster configuration element 2140. Theinteractions L2130 and L2140 may be separate for each element of theframework, as shown in dashed lines.

[0218] In an exemplary embodiment, the items marked by an [X] in FIG. 18may be defined using the OMSL.

[0219]FIG. 18 is a “model view” of a component and its surroundings. Asshown, it is centered on a given component; however, a similar view maybe made centered on another component as well.

[0220] At runtime, there corresponds to the model view of FIG. 18 a“runtime view”, e.g. as shown in FIG. 19. Component 2100 and otherscomponents 210x interact as shown at D210x to execute their tasks. Theyhave access to a database 2150, containing configuration data(“configuration” is taken here in its broadest sense), via C2100 andC210x. The component 2100 being considered works under control of theframework 2120, e.g. the CRIM, MA and CET, as shown by links M2121,M2122, M2123. The elements of the framework 2120, e.g. the CRIM 2121, MA2122 and CET 2123, may also access the data base 2150, as shown atC2121, C2122, C2123.

[0221] In fact, the framework 2120 will play a similar role for theother components. This is not shown on FIGS. 18 and 19, since they arecentered on a given element 2100.

[0222] Having thus defined how a component may be viewed, modeling acomponent in OMSL will now be considered.

[0223] Modeling may comprise defining at least one mandatory MIBs(Management Information Base) at the Component Model level, togetherwith a corresponding SAP. (It is reminded that a MIB may be attached toa SAP, which uses the MIB to deliver information corresponding to theSAP's “mission”). By so doing, the component having such MIB and SAPfollows some sort of “contract” with other components and othersurrounding functions.

[0224] An exemplary set of MIBs and SAPs will now be described.

[0225] The exemplary set of MIBs is set forth in Exhibit Eh4. The SAPnames, object names and corresponding object types are summarized intables Eh5-1, Eh5-2 and Eh5-3 of Exhibit Eh5. It should be clear thatthese examples and the MIB/SAP names are illustrative, and should notrestrict the scope of this invention.

[0226] The example involves three mandatory MIBs/SAPs:

[0227] whether it is hardware or software, a component will have acomponent type configuration MIB, to give the framework access to theconfiguration data of the component.

[0228] a software component additionally has a component instance MIB,and a component assignment MIB. Roughly, the instance is how thesoftware component exists; assignment is the role it is currentlyplaying. This distinction between instance and assignment (or role) isof interest in redundant systems. In other systems, a single MIB couldbe used for both instance and assignment.

[0229] Generally, each of these MIBs comprises a well-defined collectionof objects, as required for correct platform operation. The fact theseMIBs are defined correctly may be checked by the user who models acomponent and/or by the compiler 2030.

[0230] The objects in the MIBs may be used by the platform services(e.g. items of framework 2120) to orchestrate platform behaviorcorrectly. Concerning the names of the mandatory SAPs, of the mandatoryobjects defined by the MIBs, and the corresponding types of themandatory objects, those should be predefined by the platform architect,and not be changed thereafter. Now, there may be providedapplication-specific values to object attributes.

[0231] The Component Type Configuration MIB is a collection of softwareobjects which describe the configuration of a component type

[0232] Predefined interfaces types may be defined. In the example:

[0233] a generic ComponentDescriptor interface, which has threeattributes, as shown in table Eh5-4 in Exhibit Eh5. The OMSL descriptionof the attributes of the ComponentDescriptor interface type may be asshown in Eh4-1. I has two children:

[0234] a SoftwareComponentDescriptor, used for software components(Eh4-10); it has two additional attributes: creationDescriptor,deploymentDescriptor., which may be used to describe the component typeconfiguration as required by the CET.

[0235] a HardwareComponentDescriptor , used for hardware components(Eh4-11), which is empty, i.e. defines no additional attributes.

[0236] One object must be included in the component type configurationMIB. It is a simple object with the name componentDescriptor. ThecomponentDescriptor object implements one the above children of theComponentDescriptor interface, depending upon it is a hardware ofsoftware component. The generic ComponentDescriptor interface typedefines the component type configuration required by the frameworkservices 2120.

[0237] For both hardware and software components, thecomponentDescriptor object describes component type configuration data,e.g. the component category and redundancy model required by the CRIM.It also describes component packaging. For a software component, itadditionally describes configuration data, e.g. those needed by the CETto start up and deploy a component. The user needs to define his ownattribute values for the componentDescriptor object.

[0238] Thus, the componentDescriptor object defined by the ComponentType Configuration MIB (N11011) gives the framework (2120) access tovalues for the configuration object attributes. For example, someconfiguration data is needed by the CRIM, such as the availability modelof the component. The MIB (N11011) may be extended to hold other objectsspecific to an application.

[0239] Type configuration may be required for each component by theframework entities exploiting the OMSL language, as it will now bedescribed.

[0240] In the example, the Component Role and Assignment Manager (CRIMor 2121) requires the following component type configuration:

[0241] a component category, defined by the componentCategory attribute(Eh4-2),

[0242] a redundancy model, defined by the availabilityDescriptorattribute (Eh4-3)

[0243] a switchover escalation (see Eh4-4), which consists of count andtime window, and tells the CRIM that if the component has been restarted“count times” during the past “time window” period (in seconds), and thecomponent still experiences errors, then the unsuccessful restartrecovery should be escalated to the node switchover. The switchoverescalation count and switchover escalation time window are defined bythe availabilityDescriptor attribute.

[0244] a time out (in seconds) for a component to respond to CRIMrequests. This is defined by the availabilityDescriptor attribute.

[0245] a restartable attribute , a boolean indicating whether theassociated component type is restartable and can be recovered from sometypes of errors by restarting.

[0246] In the example, the component type configuration required by theCET (Component Executor and Terminator is provided by thecreationDescriptor attribute, and specifies (Eh4-5):

[0247] The creation time out of the component. This is the time outvalue for the component to respond back with initialization completedafter the CET has started up the component.

[0248] The binary path of the component, required to start up thecomponent.

[0249] The termination time out of a component. This is the time outvalue for the CET to receive a component termination acknowledgment,after the CET has requested the component to terminate.

[0250] The user id and the group id of the component. This is needed bythe CET when starting up the component.

[0251] A Software Load Build Tool or SLBT may be used. The SLBT requiresinformation regarding the component packages and the target platform andOS. A tool (identified as ml2swload, in the example) may provide thisinformation for the SLBT, using the following component typeconfiguration as input (Eh4-6):

[0252] The packaging descriptor, which describes component packages. Theplatform, OS, and package type (documentation, runtime or development)are described for each package that has a package name.

[0253] The deployment descriptor, which describes the target platformand OS on which to deploy a component.

[0254] The example in Eh4-20 shows how the component type configurationMIB may be used when developing a component. The predefined object name(e.g. componentDescriptor) and its corresponding type should berespected; its attribute values may be changed to be specific to a givenapplication.

[0255] This example will be described in more detail, with reference tothe operations in the flowchart of FIG. 20, and to the sub-sections inthe code of example Eh4-20:

[0256] operation 4002 (Eh4-20A) imports the relevant package for thetypes (version 1) of a SoftwareComponentDescriptor, and then defines thename of the component type (here “SoftwareComponentExample”), itsversion, type and description.

[0257] in the MIB, operation 4004 (Eh4-20B) declares the objectcomponentDescriptor, with its type as defined above. Then, one mayinitialize the desired attribute values for the componentDescriptorobject, setting the values according to the platform application to berepresented by the MIB.

[0258] operation 4006 (Eh4-20C) initializes the componentCategoryattribute.

[0259] operation 4008 (Eh4-20D) initializes the availabilityDescriptorattribute, a structure having various members.

[0260] operation 40010 (Eh4-20E) initializes the creationDescriptorattribute, another structure.

[0261] operation 40012 (Eh4-20F) initializes the packagingDescriptorattribute, an array of structures, the contents of which will beunderstood by those skilled in the art.

[0262] operation 40022 refers to the deploymentDescriptor attribute,another array of structures, which is initialized later, at the softwareload.

[0263] The instanceManagement SAP gives remote clients access to thecorresponding mandatory MIB associated with the component instance. ThisMIB consists of a collection of objects whose role is to providenecessary information associated with a component instance. One canextend the MIB with objects specific to a given application, whilerespecting the mandatory objects, as shown in example Eh4-21.

[0264] A distinct assignmentManagement SAP may be used to give remoteclients access to the component assignment MIB. This information may beused by the HA management services, such as the CRIM. One can extend theMIB with other objects specific to an application. The interface typedefines attributes related to the assignment management, for example,the usage state.

[0265] The OMSL definition of that interface may be as shown in Eh4-30.There is one mandatory object in the component assignment MIB. As theinterface is a singleton, the object does not have a name. This objectand its related type must be respected so that the platform can functioncorrectly. The object may provide the usage state of a component, whichmay be idle, or, by contrast actively in use at a specific instant, andif so, whether it has (active) or not (busy) spare capacity foradditional users at that instant. The usage state may be reported by thecomponent itself.

[0266] This state influences the decision-making aspect of platformbehavior, and is required by the HA management services, in particularthe CGHA availability services, so that a platform will run correctly.The component gives access to the usage state, which is that of itsassignment. A component instance can have only one assignment during itsprimary role. An example of how to use the assignmentManagement SAPappears at Eh4-31

[0267] To sum up, a configuration, when defined by an OMSL like CGHA-ML,may be organized as a set of MIBs, specified using the cgha:mib element.A MIB is a hierarchical tree of objects and contexts, defined using thecgha:object and cgha:context elements. In fact, the OMSL language may beused to define three categories of MIB:

[0268] MIBs associated with a specific SAP. This category of MIB iscontained within the cgha:sap element. SAP level MIBs are fullyinitialized during component instance definition or component assignmentdefinition. Component instances and assignments are defined using thecgha:instanceConfiguration element and the cgha:assignmentConfigurationelement respectively.

[0269] MIBs associated with a specific component type configuration.This category of MIB is contained within the cgha:type element.Component type configuration MIBs are initialized during component loaddefinition, using the cgha:componentLoad element, or during componenttype configuration, using the cgha:typeConfiguration element.

[0270] A MIB associated with the cluster configuration. This MIB iscontained within the cgha:cluster element. The cluster configuration MIBis initialized during cluster configuration, using thecgha:clusterConfiguration element.

[0271] The Software Load Model is another aspect of this invention.

[0272] The purpose of the Software Load Model is to define a set ofcomponents to deploy on a network element or cluster. This set ofcomponents is known as a software load. Thus, the output of the softwareload will be a list of packages (e.g. Solaris packages) defining thecomponent part of this software load. The OS (e.g. Solaris) packages arecontained in a repository and are therefore referred to by their name.

[0273] The exemplary software load model defines three elements:

[0274] cgha:softwareLoad, which is mapped to the package list file. Thecgha:softwareLoad element is the top element defining a software loadand identifies the software load.

[0275] cgha:cluster, which is not mapped to the package list file. Thecgha:cluster element is used to define the cluster on which the softwareload will be deployed.

[0276] cgha:componentLoad, which is mapped to the package list file. Acgha:componentLoad element defines a component which is part of thesoftware load. The cgha:componentLoad element first generates commentslines in the package list file identifying the component to be added.For a specific component, if no package names can be found, or if onlypackage names common to all platforms and OS are found, a warningmessage is displayed to the user. The package list is verified to ensurethat each package appears once and only once.

[0277] A standard ComponentDescriptor interface maybe used for:

[0278] defining whether the package is specific to one platform and oneOS, or common to every platform and every OS (intermediate situationsmay be covered). When writing the Component Model, the user specifieswhich package will be on which platform and OS. The targeted platformand OS are defined by their names (for example, sparc and solaris), orthe word “common” can be used to point to all platforms and/or OS.Different types of packages may be used, e.g. RUNTIME, DEVELOPMENT orDOCUMENTATION.

[0279] defining the platform and OS on which a component will bedeployed (these are also known when writing the Software Load Model).This information may be stored in a ComponentDescriptor standardinterface, using the initialization clause of the cgha:componentLoadelement.

[0280] When compiling the Software Load Model, the compiler will lookfor the ComponentDescriptor standard interface to retrieve informationregarding the platform and the OS on which the Software Load will bedeployed. With this information, package names will be found. Finally,only package names with RUNTIME type are retained.

[0281] A softwareLoad Description file may be used to describe asoftware load in OMSL, in the following way:

[0282] It first shows the description element, then a list of importsneeded to use components and interfaces already defined.

[0283] It then defines a cluster. Since this definition is not part ofthe OMSL to Software Load mapping, it is not considered here.

[0284] Finally, each component part of this software load is enumerated.

[0285] For some components, the platform and OS are initialized (forexample the CRIM component).

[0286] The Component Descriptor will now be considered. By looking atthe Component Model for every component included in the software loadpreviously defined, it is possible to see which package names will beoutput. For example:

[0287] in a BootServer Component, no package names are declared, thestructure PackagingDescriptor is not initialized. No package names willappear in the package list.

[0288] a CEC component defines package names for every platform and OS,but the platform and OS are not initialized in the software load. Thus,no package names appear in the package list.

[0289] there may be package names defined specifically for each platformand each OS, plus some package names that are common to every platformand OS. The software load does not initialize the platform and the OS,but the common package names are output.

[0290] turning to the CRIM Component, there may be package names definedspecifically for each platform and each OS, plus some package names thatare common to every platform and OS. In this example, the software loadinitializes platform and OS to Sparc and Solaris.

[0291] The platform update model is now considered again.

[0292] Reference is now made to FIG. 21, which shows how an OMSLlanguage facilitates a platform update operation. In this example, aHA-cluster HACx is considered.

[0293] Before the update, cluster HACx is in a previous state st-ante,with a Current Load 1 (denoted cl-ante), comprising software load imageswl_ante, and configuration update cnf-ante. This is reflected in thecurrentLoad.1.xml file or package in the OMSL language, e.g. CGHA-ML.

[0294] The update itself is defined in the platformUpdate.2.xml file orpackage. In the example, it comprises softwareLoad.2.xml andconfigurationUpdate.2.xml.

[0295] From these files, the status st-post after the update may be:

[0296] defined, by currentLoad.2.xml file or package in the OMSLlanguage, and

[0297] prepared to have Current Load 2, denoted cl-post, comprisingsoftware load image swl_post, and configuration update cnf-post, whichmay be loaded into cluster HACx.

[0298] As shown in FIG. 22, a platform update may be entirely definedfrom an XML package PLTF_UPDT, stored in repository 1520, genericallynamed platformUpdate.<version>.xml, and comprising:

[0299] a currentLoad.<version>.xml (2820),

[0300] a softwareLoad.<version>.xml (2840),

[0301] one or more configuration Update.<version>.xml.(2860)

[0302] Furthermore, the XML data may be used by a tool (denotedml2config in the example), to produce aplatformUpdate.<version>.next.xml (“next” here means “next current”) at2840.

[0303] The tree structure used with OMSL may be conveniently representedin a directory system like LDAP. Thus, FIG. 22 additionally shows LDAPdata, e.g.:

[0304] platformUpdate.<version>.populate.ldif at 2842

[0305] platform Update.<version>.apply.ldif at 2844

[0306] platform Update.<version>.rollback.ldif at 2846

[0307] platform Update.<version>.remove.ldif at 2848

[0308] The LDAP data may be stored at 2400 in FIG. 10, as anotherrepresentation of the OSML tree, which may be readily accessed atruntime. The aspects of mapping from OMSL to a directory system likeLDAP will be described hereinafter. For the time being, the parallelOMSL and LDAP trees are considered commonly as an “OMSL/LDAP tree”.

[0309] A platform update process may have different forms:

[0310] i) it may update just the configuration associated with a MIB.Such an update of the configuration alone is reflected by incrementingthe update level of the MIB.

[0311] Ii) it may update both the structure and the configurationassociated with a MIB. An update of both structure and configuration isreflected by incrementing the version of the MIB container (cluster orcomponent).

[0312] It should be noted that the version and update level are alsopart of the OMSL/LDAP naming tree.

[0313] If the MIB has been updated, then during the platform updateprocess, there are simultaneously two different MIB configurations, withtwo corresponding sub-trees in OMSL/LDAP, respectively. One correspondsto the MIB configuration before starting the update process, (st_ante inFIG. 21) and the other corresponds to the MIB configuration after theupdate process (st_post in FIG. 21).

[0314] The platform update table may be a part 28422 of item 2842 inFIG. 22, together with the LDAP MIBs 28420.

[0315] To have access to its configuration, a component must know theupdate level corresponding to each MIB. When a component is running, theupdate level can change. A uniform mechanism is available to access MIBconfiguration at runtime, using the platform update table. This platformupdate table provides a mapping between a MIB container name and theassociated configuration tree. The table contains the identifiers (e.g.LDAP Distinguished Names or DNs) of all the MIBs that are defined. A newplatform update table is generated for each new platform update. Theplatform update table is accessed indirectly by means of the version ofthe software load. Each software load contains the DN of the appropriateversion of the platform update table.

[0316] To summarize, the Platform Update mechanism is organized in thefollowing way:

[0317] Each MIB is fully defined by its container (cluster, componenttype, SAP), the version of the cluster or the component type and itsupdate level.

[0318] A platform update table, containing the identifiers (e.g. LDAPDNs) of all the MIBs defined, is provided for each platform updateversion.

[0319] The identifier (e.g. DN) of the appropriate platform update tableis provided for each software load version.

[0320] The OMSL/LDAP trees are used in FIGS. 23 through 27, in which theLDAP information is diagrammatically shown.

[0321]FIG. 23 considers the configuration of a component, here a clusterCLS1, which has an instance “i” and an assignment interface “a”. In FIG.23:

[0322] a component type configuration MIB 3000 reflects the type of thecomponent in the OMSL (e.g. CGHA-ML), and is mapped into a correspondingLDAP sub-tree “CLS1,1”.

[0323] a component instance MIB 3002 has access to the MIB 3000 (asdefining the LDAP sub-tree CLS1,1 which corresponds to the “internal”type of the component). It defines the “instance” of the component usinga “SAP name”. This is reflected both internally in the component at3012, which is shown as an interface, and is mapped in a correspondingLDAP sub-tree “cls,instance1,1”. Other components, and managementfunctions, may thus be aware of what component CLS1 can do.

[0324] a component assignment MIB 3004 has access to the MIB 3002 (asdefining what the component can do). It defines the “assignment” of thecomponent using a “SAP name”. This is reflected both internally in thecomponent at 3014, which is shown as another interface, and is mapped ina corresponding LDAP sub-tree “cls,assignment1,1”. Other components, andmanagement functions, may thus be aware of what component CLS1 actuallydoes.

[0325] Thus, a software update may take place as shown in FIG. 24 (TheMIBs are not shown, for more clarity in the drawing). New “values” (infact complete sets of data), suffixed 2,1 have been loaded in therepositories and mapped to LDAP. The component CLS1 initially workingunder “1,1” is rebooted, and then works as “2,1”. (In fact, as shown,this may also occur when only a node of the cluster is rebooted). Ofcourse, the new values “2,1” need not be entirely different from the oldones “1,1”. In certain cases, they may even remain identical (rebootwithout change).

[0326]FIG. 25 shows a configuration update, made in response to aconfiguration update event (for example a “sleeping” node should besubstituted to a failing node). The situation is similar to that of FIG.24, except that there is no reboot, and the “cls,instance 1,1” and thecorresponding instance MIB (not shown) is not modified.

[0327]FIG. 26 shows again the component CLS1 of FIG. 23, with itsinterfaces 3012 (instance) and 3014 (assignment), now under control ofmanagement functions 3022 and 3024. Interface 3016 “exposes” theservices offered by the component to other components. Interface 3018enables the “callback”, used e.g. for connection with the platformservices.

[0328] Redundancy may be managed as illustrated in FIG. 27. Two“equivalent” components CLS1A and CLS1B are shown, with the sameinterfaces as in FIG. 26, suffixed with “A” or “B”. LDAP data 3400 havedistinct sub-trees for the instances 3012A and 3012B, however the samesub-tree for the assignments 3014A and 3014B.

[0329] A management agent 3500 accesses interfaces 3012A, 3012 B and3014A, and builds e.g. corresponding Mbeans, assuming the applicantcompany's JDMK is being used.

[0330] Thus, by having the management agent 3500 accessing the LDAPdata, the software management may be conducted with knowledge of whatthe component CLS1A in service can do, and actually does, and of whatthe “sleeping” component CLS1B can do. The management agent 3500, e.g.via the Mbeans, controls the management interfaces 3012A, 3012B and3014A accordingly.

[0331] While the OMSL language may form a basis for organizing namedobjects and configuration data, a directory system may be convenientlyused to make such objects and data available at runtime. This has beenshown in FIGS. 22 through 27, with the directory system being an LDAPdirectory server in these examples.

[0332] This may make use of a mapping from an OMSL to a directory systemlike LDAP (Lightweight Directory Access Protocol). Such a mapping is nowconsidered. The language being used on the directory system side ishereinafter generically termed Directory System Software Language, or,in short, DSSL.

[0333] In this OMSL-to-DSSL mapping section of this specification ,reference will be made to LDAP examples as follows:

[0334] Exhibit Eh7 shows exemplary LDAP configuration objects,

[0335] Exhibit Eh8 contains illustrative tables,

[0336] Exhibit Eh9 contains an exemplary LDAP object, i.e. a componenttype configuration MIB.

[0337] In the examples, the directory system is based on LDAP, and theDSSL uses the LDAP Data Interchange Format (LDIF) syntax. The LDIFformat is a standard way of representing directory data in a textualformat. However, the LDIF format is exemplary only, and other DSSLnotations may be used as well.

[0338] The diagram Eh7-0 in Exhibit Eh7 shows an exemplary LDAP layout.A corresponding LDAP Schema may adopt the overall organization reflectedin the LDAP layout being shown. In accordance with another aspect ofthis invention, at least some of the layout items have a “version”qualifier or entry. In the example, every layout item has a “version”qualifier or entry.

[0339] In accordance with still another aspect of this invention, atleast some of the layout items have an “update level” qualifier orentry. In the example, an “update level” is defined for the cluster,types, instances and assignments.

[0340] It should also be kept in mind that the LDIF format is “reversed”with respect to the “directory-like” description of a tree structure.For example:

[0341] the LDIF notation leaf_node, nexus2, nexus1, root corresponds to

[0342] the directory-like notation root\nexus1\nexus2\leaf_node

[0343] Accordingly, when converting the exemplary LDAP layout (shown inthe diagram Eh7-0 in Exhibit Eh7) into in a corresponding treestructure, the respective levels of “update level” and “version” arereversed.

[0344] In other words, applying this e.g. to the examples in the diagramEh7-0 would result into:

mib\update level\version\<referenced object>,

[0345] where<referenced object> may be:

[0346] cluster

[0347] component type\type

[0348] sap\component instance\instance

[0349] sap\component assignment\assignment

[0350] The RDN of the referenced object will be primarily defined, usinge.g. the LDAP resources as defined below.

[0351] Now, it may be desirable to include in the name of the LDAPobject a “version” and/or “update level” qualifier. In accordance with afurther aspect of this invention, this may be made as follows:

[0352] each MIB is fully defined by its container (cluster, componenttype, SAP), the version of the cluster or the component type, and itsupdate level;

[0353] for each platform update version, there is defined acorresponding platform update table, containing the DNs of all the MIBsbeing defined in that platform update version;

[0354] the DN of the accurate platform update table is provided for eachsoftware load version.

[0355] Now, in order to obtain the DN of a <referenced object> (asdefined above), the relevant platform update table may be used to obtainthe version and update level defining the relevant MIB configuration,and to concatenate that with the RDN previously defined for the<referenced object>.

[0356] The currently available platform update table may also besearched, e.g. upon a “system event” in the platform to know the namesof the current configuration entities, and then read suchconfigurations, as desired.

[0357] In an embodiment, only one set of LDAP data (or similar directorydata) is available at a given time, in accordance with the currentconfiguration of the platform, except at the time of a platform update,where a new set of LDAP configuration data is also available (e.g.mapped from a new platform update defined in OMSL). This is accompaniedwith a transactional processing of LDAP data, enabling “commit” if thechange from the current configuration to the new one is validated, or,else, a “rollback”. Then:

[0358] in the case of a “commit”, the LDAP data corresponding to theprevious configuration may be erased, with only the LDAP data of the newconfiguration remaining;

[0359] conversely, in the case of a “rollback”, the LDAP datacorresponding to the (would-be) new configuration may be erased, withonly the LDAP data of the initial current configuration remaining.

[0360] This makes it possible to avoid encumbering the LDAP data with anhistorical succession of configuration data, which may render itdifficult to write new LDAP data, in an LDAP tree being progressivelymore and more encumbered.

[0361] An example of an LDAP implementation will now be described.

[0362] LDAP object classes may be defined, e.g. as shown in the rest ofExhibit Eh7. The object classes may comprise generic object classes, andobject classes related to the above defined entities of the OSML.Amongst the exemplary generic object classes:

[0363] a generic object class cgha-attribute--oc (Eh7-O1) may beprovided to name sub-entries corresponding to array or map attributes orto structure type attributes. This object class contains an attributecgha-attribute-name, which is used to define the RDN of the attribute.

[0364] a generic object class cgha-member--oc (Eh7-O2) maybe provided inorder to name sub-entries corresponding to map or array members, ormembers of structure type. This object class contains an attributecgha-member-name used to define the RDN of the member.

[0365] a generic object class cgha-element--oc (Eh7-O3) is provided inorder to name the map and array items. This object class contains anattribute cgha-key used to define the RDN of the item.

[0366] The syntax used in mapping OMSL attributes to LDAP may be asshown in table Eh8-T1 in Exhibit Eh8: the Directory String syntax may beused for attributes that are RDNs (Relative Distinguished Names), andmay be tagged as single value; the Distinguished Name syntax may be usedfor attributes that contain a DN; the “IA5” String syntax may be used inthe remaining cases.

[0367] The other object classes will be discussed hereinafter as needed.(The syntax and “value tag” of the attributes in the LDAP object classesis shown in Exhibit Eh7, and will not be commented in the followingdescription).

[0368] Thus, an LDAP configuration (more generally, a set of directorysystem configuration data) may be generated, using such genericattributes and object classes. In the example, these generic entitiesmay be grouped into a single LDIF file, which may be used to populatethe LDAP server with directory entries during the initialization of theOMSL Software Platform.

[0369] In the exemplary embodiment, the directory system is used to“read” the platform configuration, from within the platform in use.Then, what has to be represented in LDAP is the platform configurationinformation that is described using the OMSL (e.g. CGHA-ML).Hereinafter, an OMSL entity that contains configuration information istermed “configuration-oriented” (or, in short, “configuration”). Forexample, a CGHA-ML attribute (cgha:attribute element) is“Configuration-oriented” if it has its configuration attribute set toyes.

[0370] The following section describes how “configuration-oriented” OMSLentities may be mapped to LDAP entries. Other OMSL entities may bemapped to LDAP, if desired.

[0371] Generally, each entry is composed of a set of LDAP attributes,which contains the data from the OMSL object, associated with the entry.Sub-entries may also be used, as it will be understood.

[0372] As known, LDAP entries may be specified using an LDAP schema,which may be implemented as follows:

[0373] the schema of the LDAP server is reflected in an LDAPconfiguration tree (by contrast with a “user” tree, which contains theuser data to be “read” by the platform functions);

[0374] the LDAP configuration tree should be updated with corresponding“schema” entries before importing the corresponding configuration of theplatform as “user” entries in the LDAP server.

[0375] conversely, before a class can be removed from the LDAP schema,the corresponding entries should be removed.

[0376] Now, mapping OMSL entities (e.g. types) to LDAP involvesgenerating LDAP attributes and object classes in the LDAP schema, andtherefore defining their names.

[0377] The common LDAP naming schema of attributes and object classes isa single flat naming space. Thus, when mapping OMSL type identifiers toLDAP, one or more of the following rules may be used, as done in theexemplary embodiment:

[0378] certain characters are not allowed in the names of LDAPattributes and object classes. The period character (.) may be replacedin the mapping by the dash character (-). The underscore character (_)may be mapped by removing it and by converting the next character intoan uppercase character.

[0379] The version of the type is taken into account when this versionis provided (LDAP does not offer explicit support for versioning).

[0380] The string--oc is added to object class names in order todifferentiate them from attribute names.

[0381] Each entity has an OID, which may be generated from the name ofthe entity, e.g. by concatenating the name of the entity in lower casewith the addition of the string -oid, as currently required by LDAPservers.

[0382] The above will be referred to as “id-mapping rules”, whethertaken together or in part.

[0383] The first level of mapping refers to generic constructs, whichinclude the OMSL types.

[0384] By providing that the LDAP fully qualified name of a type isunique, it may be used as a basis for naming LDAP entities related tothis type. Thus, the LDAP naming schema may be further extended to nameLDAP attributes corresponding to attributes of interfaces, or members ofstructures. The resulting name may be obtained by concatenating the typename and the sub-entry name and separating them e.g. by the dashcharacter (-).

[0385] Now, a OMSL attribute may be mapped in different ways: an LDAPattribute, or an LDAP entry:

[0386] an LDAP entry may be used if the OMSL attribute is of “pluralnature” (structure type, or map or array). The LDAP entry is providedwith sub-entries, which are used to hold that plurality (members of thestructure, or the items of the map or array). In other words, if theattribute is an array or a map, each item of the array or map is mappedto a sub-entry of the entry representing the array or map (as a whole).Thus, an object class containing only the LDAP attribute is generated.The name of this object class is based on the name of the attributecompleted with the string--oc.

[0387] by contrast, where an OMSL attribute is “single-valued” (simple),it may be mapped directly to an LDAP attribute, tagged as single value.The LDAP attribute may be named as described above (id-mapping rules),along the IA5 String syntax, as shown in table Eh8-T0. In other words,at the object level in the LDAP schema, if the attribute is not an arrayor a map, the resulting LDAP attribute is part of the object classcorresponding to the interface (or other object) containing the OMSLattribute.

[0388] Table Eh8-T11 shows an exemplary mapping of OMSL attribute typesto LDAP in more detail. With reference to the row labels in TableEh8-T11:

[0389] Row1: a “simple” attribute is mapped to an LDAP attribute.

[0390] Row2: in the case of a “simple” type attribute that is an array,an LDAP attribute is created to represent the array, together with anentity adapted to represent the items of the array. The entity may be inturn an object class, containing an attribute. Then, the array items arerepresented as LDAP sub-entries, instantiating the object class.

[0391] Row 3: the case of an enumeration type attribute may be treatedsimilarly: it is mapped to an LDAP attribute, which itself is anattribute of an LDAP object class corresponding to the nature of theoriginal enumeration.

[0392] Row 4: turning now to Structure Type Attributes, an attribute ofstructure type is mapped to LDAP by mapping the structure to LDAP, asdescribed hereinafter. The configuration associated with the attributeis mapped as a sub-entry in the LDAP configuration tree. The name of theattribute is used as the RDN of the sub-entry.

[0393] Table Eh8-T12 shows how various OMSL entities (GGHA-ML in theexample) may be mapped to an LDAP schema.

[0394] Consider for example the case of mapping OMSL members to LDAPSchema, as shown in table Eh8-T12, row 2. A OMSL member is defined froma cgha:member element, in the exemplary CGHA-ML. Now:

[0395] If the OMSL member is part of a structure mapped to LDAP, it isitself mapped to LDAP according to its type (for example, simple type,enumeration type, structure type).

[0396] otherwise, a simple type member is mapped directly to an LDAPattribute, named as described above and tagged as single value.Concerning the “object class” level:

[0397] if the member is not an array or a map, the resulting LDAPattribute is part of the object class corresponding to the structurecontaining the OMSL member.

[0398] if the member is an array or a map, each item of the array or mapis mapped to a sub-entry. In this way, an object class containing onlythe LDAP attribute is generated. The name of this object class is basedon the identifier of the attribute completed with the string--oc.

[0399] a member that is itself of structure type is mapped to LDAP bymapping the structure to LDAP. The configuration associated with theattribute is mapped as a sub-entry in the LDAP configuration tree. Thename of the member is used as the RDN of the sub-entry.

[0400] After having defined the mapping the generic constructs, the MIBswill now be considered. It is reminded that a MIB or ManagementInformation Base is associated with a OMSL entity (SAP, component typeconfiguration, cluster configuration, in the example), and has acorresponding container (cgha:sap, cgha:type, cgha:cluster,respectively)

[0401] Each MIB may be mapped to an LDAP tree of entries, which maycontain the following:

[0402] any OMSL object (when “configuration oriented”, in the example)is mapped in this tree as an LDAP entry, which may have sub-entries.

[0403] furthermore, any OMSL object having a nested object (if“configuration oriented”) is also mapped in this tree of entries.

[0404] Mapping OMSL configuration to LDAP entries may be considered inthe following order:

[0405] contents of the MIBs: Maps and Arrays, Init values, Objects,contexts;

[0406] binding between the MIBs and the OMSL/LDAP configuration space:Cluster Configuration, Component Type Configuration, Component InstanceConfiguration, Component Assignment Configuration, and SAPs;

[0407] overall platform update configuration: Platform Update, SoftwareLoad.

[0408] OMSL elements which are designated as a map or an array aremapped to LDAP as sub-entries of the LDAP entry corresponding to the mapor array. (This mapping may be used for objects, contexts, attributesand members). The map and array items maybe named using the genericobject class cgha-element--oc. The sub-entries belong to the LDAP objectclass corresponding to the type of the element which is a map or anarray. If the element is of simple type, the sub-entries belong to theobject class that has been created specifically.

[0409] Simple type init values are mapped to LDAP using IA5 Stringsyntax, applied to the string that has been used as value in thecgha:init element.

[0410] Similarly, Enumeration init values are mapped to LDAP using IA5String syntax. The string that is stored in LDAP is the value of theenumeration value (cgha:enumValue element) that has been selected in thecgha:init element.

[0411] Mapping OMSL Structures is now considered.

[0412] Consider first reflecting in LDAP the fact that a OMSL attributeor member is of structure type. It is mapped to an LDAP entry (which mayhave sub-entries, e.g. if the attribute or member is an array or a map,or if one of the members of a structure is itself a structure or is anarray or a map). The generic object class cgha-structure--oc (Eh7-O4) isused. Its cgha-structure-type attribute defines the fully qualified typename of the structure. A cgha-structure-version attribute holds thestructure version, if the structure has a version.

[0413] Now turning to Mapping a Structure (contents), the LDAP entry ofan attribute or a member which is a structure, but which is not an arrayor a map, is defined by:

[0414] Its DN. The identifier of the OMSL attribute or member is used asRDN.

[0415] Its generic object classes:

[0416] cgha-attribute--oc or cgha-member--oc

[0417] cgha-structure--oc.

[0418] Its generated object classes based on the type of the structure,following the mapping defined above.

[0419] Its attributes, some of which are used to store the valuesassociated with simple type members.

[0420] Its sub-entries, used to store the values associated withstructure type members.

[0421] The case of mapping an Array or a Map of Structures will now bedescribed. The LDAP entry corresponding to a structure type attribute ormember that is an array or a map is defined by:

[0422] Its DN. The identifier of the OMSL attribute or member is used asRDN.

[0423] Its generic object classes:

[0424] cgha-attribute--oc, or cgha-member--oc

[0425] cgha-structure--oc.

[0426] Its sub-entries, used to store the values associated with theitems of the array or map. Each LDAP sub-entry is defined by:

[0427] Its DN. The key of the item is used as RDN.

[0428] Its generic object classes:

[0429] cgha-element--oc

[0430] cgha-structure--oc

[0431] Its-generated object classes, based on the type of the structure,following the mapping defined above,

[0432] Its attributes, used to store the values associated with simpletype members.

[0433] Its sub-entries, used to store the values associated withstructure type members.

[0434] Mapping Object References is now considered. A OMSL attribute ormember that is an object reference is mapped to an LDAP entry, which mayhave sub-entries, e.g. if the attribute or member is an array or a map.The generic object class cgha-object-reference--oc contains thefollowing four attributes (Eh7-O5):

[0435] cgha-object-reference-type, which defines the fully qualifiedtype name of the object reference.

[0436] cgha-object-reference-version, which defines the version of theobject reference.

[0437] cgha-object-reference-mib-dn, which is used to store the DN ofthe container of the MIB (cluster, component type or SAP), withouttaking into account the version and update level.

[0438] cgha-object-reference-full-name, which is used to store the fullname of the referenced object, as described.

[0439] Thus, the LDAP entry of an attribute or a member which is anobject reference, but which is not an array or a map, may be defined by:

[0440] Its DN. The identifier of the OMSL attribute or member is used asRDN.

[0441] Its generic object classes:

[0442] cgha-attribute--oc or cgha-member--oc

[0443] cgha-object-reference--oc.

[0444] Its generated object classes based on the type of the objectreference, following the corresponding mapping, as above defined.

[0445] Its attributes.

[0446] In order to obtain the DN of the referenced object, the platformupdate table 28422 (FIG. 22) may be used to obtain the version andupdate level defining the MIB configuration, and to concatenate thatwith the RDN previously defined for the cgha-object-reference-full-nameattribute.

[0447] Mapping an Array or a Map of Object References is now considered.The LDAP entry corresponding to an object reference type attribute ormember that is an array or a map is defined by:

[0448] Its DN. The identifier of the OMSL attribute or member is used asRDN.

[0449] Its generic object classes:

[0450] cgha-attribute--oc or cgha-member--oc

[0451] cgha-object-reference--oc.

[0452] Its sub-entries used to store the values associated with theitems of the array or map. Each LDAP sub-entry is defined by:

[0453] Its DN. The key of the item is used as RDN.

[0454] Its generic object classes, cgha-element--oc,cgha-object-reference--oc

[0455] Its generated object classes, based on the type of the objectreference, following the mapping defined above for Object References.

[0456] Its attributes, some of which may be used to store the valuesassociated with simple type members.

[0457] Mapping OMSL References is now considered. A OMSL attribute ormember that is a reference and that is part of the configuration ismapped to an LDAP entry, which may have sub-entries. Sub-entries arenecessary if the attribute or member is an array or a map. The genericobject class cgha-reference--oc contains the following two attributes:

[0458] cgha-reference-type, which defines the fully qualified type nameof the reference.

[0459] cgha-reference-dn, which is used to store the DN of thereferenced component instance or assignment.

[0460] Mapping a Reference (per se) may now be described. The LDAP entryof an attribute or a member which is a reference, but which is not anarray or a map, is defined by:

[0461] Its DN. The identifier of the OMSL attribute or member is used asRDN.

[0462] Its generic object classes:

[0463] cgha-attribute--oc if it is an attribute or cgha-member--oc if itis a member

[0464] cgha-reference--oc.

[0465] Its generated object classes based on the type of the reference,following the mapping defined above for References

[0466] Its attributes.

[0467] Turning now to mapping an Array or a Map of References, the LDAPentry corresponding to a reference type attribute or member that is anarray or a map is defined by:

[0468] Its DN. The identifier of the OMSL attribute or member is used asRDN.

[0469] Its generic object classes:

[0470] cgha-attribute--oc or cgha-member--oc

[0471] cgha-reference--oc.

[0472] Its sub-entries used to store the values associated with theitems of the array or map. Each LDAP sub-entry is defined by:

[0473] Its DN. The key of the item is used as RDN.

[0474] Its generic object classes:

[0475] cgha-element--oc

[0476] cgha-reference--oc

[0477] Its generated object classes, based on the type of the reference,following the mapping defined above for References

[0478] Its attributes.

[0479] Mapping Objects to LDAP is now considered.

[0480] A OMSL object (specified e.g. with cgha:object) that implementsan interface containing configuration attributes is called aconfiguration[-oriented] object. Each configuration object is mapped toan LDAP entry, with LDAP sub-entries if the implemented interfacecontains map or array attributes or structure type attributes. If theobject contains nested objects that are also configuration objects, theyare mapped as sub-entries of the entry corresponding to the enclosingobject.

[0481] The generic object class cgha-object--oc (Eh7-O7) contains oneattribute cgha-object-name used to define the RDN of the object in theLDAP tree.

[0482] The generic object class cgha-interface--oc (Eh7-O8) contains thefollowing two attributes:

[0483] An attribute named cgha-interface-type that defines the fullyqualified type name of the interface.

[0484] An attribute named cgha-interface-version that holds the versionof the interface.

[0485] An object that implements a singleton interface and that is aconfiguration object, is mapped directly in the containing SAP. Thismeans that the generated object class is added to the list of objectclasses provided by the LDAP entry corresponding to the SAP (asdescribed). If the object contains nested configuration objects and ifit is not a configuration object itself, the associated entry belongsonly to the object class cgha-object--oc.

[0486] Mapping an Object That Is Not a Map to LDAP is now considered.The LDAP entry that corresponds to a configuration object is defined by:

[0487] Its DN. The identifier of the OMSL object is used as RDN.

[0488] Its generic object classes:

[0489] cgha-object--oc.

[0490] cgha-interface--oc.

[0491] Its generated object class(es) based on the type of theinterface(s) implemented by the object. There is an object class for theinterface implemented by the object and for each of the ancestors ofthat interface.

[0492] Its attributes.

[0493] Its sub-entries, used to store the values corresponding to:

[0494] Structure type attributes.

[0495] Nested objects or contexts.

[0496] The generic attributes cgha-interface-type andcgha-interface-version are initialized to define the fully qualifiedtype name and version of the interface that is implemented by theobject. The LDAP attribute resulting from mapping the category attributeis initialized based on the value provided in the configuration.

[0497] Mapping a Map of Objects to LDAP is now considered. The LDAPentry that corresponds to a map of configuration objects is defined by:

[0498] Its DN. The identifier of the OMSL object may be used as RDN.

[0499] Its generic object classes: cgha-object--oc. andcgha-interface--oc.

[0500] Its sub-entries, used to store the values corresponding to eachitem of the map. Each LDAP sub-entry is defined by:

[0501] Its DN. The key of the map item is used as RDN.

[0502] Its generic object classes cgha-element-oc and cgha-interface-oc.

[0503] Its generated object class(es) based on the type of theinterface(s) implemented by the object.

[0504] Its attributes.

[0505] Its sub-entries (if any).

[0506] Mapping OMSL Contexts to LDAP is now considered.

[0507] A OMSL context (specified using the cgha:context element) thatcontains nested configuration objects is mapped to an LDAP entry. Thenested configuration objects are mapped as sub-entries of the entrycorresponding to the context. If the context corresponds to a map, theitems of the map are mapped to sub-entries of the entry corresponding tothe context.

[0508] The generic object class cgha-context--oc (Eh7-O9) contains oneattribute, cgha-context-name, which is used to define the RDN of theentry in the LDAP tree.

[0509] Mapping a Context That Is Not a Map to LDAP is now considered.The LDAP entry that is associated with a context that is not a map isdefined by:

[0510] Its DN.

[0511] A generic object class cgha-context--oc.

[0512] Its sub-entries, which are used to map nested objects orcontexts.

[0513] Mapping a Context That Is a Map to LDAP is now considered. TheLDAP entry that is associated with a context that is not a map isdefined by:

[0514] Its DN.

[0515] the generic object class cgha-context--oc.

[0516] Its sub-entries, which are used to map the items of the map, andnested objects or contexts.

[0517] Each LDAP sub-entry is defined by:

[0518] Its DN. The key of the map item is used as RDN.

[0519] Its generic object class cgha-context--oc

[0520] Its sub-entries.

[0521] Mapping OMSL Cluster Configuration to LDAP is now considered.

[0522] The cluster configuration may be mapped as sub-entries of theLDAP entry ou=cluster, o=cgha_root. The cluster configuration may bemapped taking into account its version and its update level. The clusterconfiguration MIB is mapped as sub-entries of the resulting entry. Thefirst sub-entry corresponds to the version of the cluster configuration.Its update level is nested inside the version sub-entry. The MIB(hierarchical tree of objects associated with the MIB) is nested withinthe update level sub-entry.

[0523] The version is mapped to an LDAP entry that belongs to thegeneric object class cgha-cluster-version--oc. This object class(Eh7-O10) contains one attribute cgha-cluster-version used to define theversion of the configuration.

[0524] The update level is mapped to an LDAP entry that belongs to thegeneric object class cgha-cluster-update-level--oc. This object class(Eh7-O11) contains one attribute cgha-cluster-update-level used todefine the update level of the configuration.

[0525] Mapping OMSL Component Type Configuration to LDAP is nowconsidered. Component type configuration is mapped as sub-entries of theLDAP entry ou=types,o=cgha_root.

[0526] Component type configuration is mapped taking into account thefully qualified type name of the component, its version and its updatelevel. The component type configuration MIB is mapped as sub-entries ofthe resulting entry.

[0527] The fully qualified type name is mapped to an LDAP entry thatbelongs to the generic object class cgha-component-type--oc. This objectclass (Eh7-O12) contains one attribute cgha-component-type used todefine the fully qualified type name of the component.

[0528] The version is mapped to an LDAP entry that belongs to thegeneric object class cgha-component-type-version--oc. This object class(Eh7-O13) contains one attribute cgha-component-type-version used todefine the version of the component.

[0529] The update level is mapped to an LDAP entry that belongs to thegeneric object class cgha-component-type-update-level--oc. This objectclass (Eh7-O14) contains one attribute cgha-component-type-update-levelused to define the update level of the configuration.

[0530] Mapping OMSL Component Instance Configuration to LDAP is nowconsidered.

[0531] Component instance configuration is mapped as sub-trees of theLDAP entry ou=instances, o=cgha_root. Component instance configurationis mapped taking into account its identifier, the identifier of the SAPcontaining the configuration, the component type version and the updatelevel of the instance configuration. The MIBs corresponding to thecomponent instance configuration are mapped as sub-entries of theresulting entry.

[0532] The component instance identifier is mapped to an LDAP entry thatbelongs to the generic object class cgha-component-instance-name--oc.This object class (Eh7-O15) contains two attributes:

[0533] cgha-component-instance-name used to define the identifier of theinstance.

[0534] cgha-component-type used to define the fully qualified type nameof the instance.

[0535] The component instance update level is mapped to an LDAP entrythat belongs to the generic object classcgha-component-instance-update-level--oc. This object class (Eh7-O16)contains one attribute cgha-component-instance-update-level used todefine the update level of the configuration.

[0536] Mapping OMSL Component Assignment Configuration is nowconsidered.

[0537] Component assignment configuration is mapped as sub-trees of theLDAP entry ou=assignments, o=cgha_root. Component assignmentconfiguration is mapped taking into account its identifier, theidentifier of the SAP containing the configuration, the component typeversion and the update level of the assignment configuration. Thecomponent assignment configuration MIBs are mapped as sub-entries of theresulting entry. The identifier is mapped to an LDAP entry that belongsto a generic object class cgha-component-assignment-name--oc. Thisobject class (Eh7-O17) contains two attributes:

[0538] cgha-component-assignment-name used to define the name of theassignment.

[0539] cgha-component-type used to define the component type of theassignment.

[0540] The component assignment update level is mapped to an LDAP entrythat belongs to a generic object classcgha-component-assignment-update-level--oc. This object class (Eh7-O18)contains one attribute cgha-component-assignment-update-level used todefine the update level of the configuration.

[0541] Mapping OMSL SAPs to LDAP is now considered. SAPs are definedusing the cgha:sap element (as specified above). SAPs are mapped to LDAPas sub-entries of the entry corresponding to the component instance (asdescribed above) or component assignment (as described above) thatcontains the SAP.

[0542] The name is mapped to an LDAP entry that belongs to the genericobject class cgha-sap-name--oc. This object class (Eh7-O19) contains twoattributes:

[0543] cgha-sap-name used to define the name of the SAP.

[0544] cgha-ap-access used to specify whether the SAP will be exposed toa supervisor authority, e.g. an OMC (Operation & Management Center). Thevalue management indicates that the SAP is exposed to the OMC. The valuecluster indicates that the SAP is only exposed to cluster components.

[0545] Mapping the OMSL Platform Update to LDAP is now considered.

[0546] In order to provide a consistent view of the Network Elementconfiguration, it is desirable to generate the list of update levelsassociated with all the MIBs defined in the platform update (specifiedusing the cgha:platformUpdate element). This list is implemented in LDAPas a sub-entry of the LDAP entry ou=platform_updates, o=cgha_root. Thelist is implemented taking into account the version of the platformupdate: the version is mapped as the first sub-entry ofou=platform_updates, o=cgha_root, and the list of update levels isnested inside the sub-entry corresponding to the version. One entry inthe list of update levels is generated per MIB.

[0547] The version is mapped to an LDAP entry that belongs to a genericobject class cgha-platform-update-version-oc. This object class(Eh7-O20) contains one attribute cgha-platform-update-version used todefine the version of the platform update.

[0548] The list of MIB update levels is implemented in LDAP as a set ofentries belonging to a generic object class cgha-update-level--oc. Thisobject class (Eh7-O21) contains three attributes:

[0549] the attribute cgha-component-update-level, which is used todefine the RDN of the element in the list. Its value is the DN of theMIB including the associated version.

[0550] the attribute cgha-component-update-level-dn, which is used todefine the DN of the MIB, including its update level.

[0551] the attribute cgha-updated, which is used to define if the MIBhas been updated in the platform update. This attribute is set to 1 ifthe MIB has been updated and to 0, otherwise.

[0552] Mapping the OMSL Software Load to LDAP is now considered.

[0553] The software load version provides the means to access thecorrect version of the platform update table. This is implemented inLDAP as a sub-entries of the LDAP entry ou=software_loads, o=cgha_root,taking into account the version of the software load.

[0554] The version is mapped to an LDAP entry that belongs to a genericobject class cgha-software-load-version--oc. This object class (Eh7-O22)contains two attributes:

[0555] cgha-software-load-version, used to define the version of thesoftware load.

[0556] cgha-platform-update-dn, used to define the DN of the currentplatform update table. This current platform update table corresponds tothat defined by the <prefix>.apply.ldif file (described hereinafter).

[0557] A file used to apply the platform update may contain the entry asshown in second place, which sets the current platform update DN.

[0558] Removing LDAP Entries is now considered. LDAP entries must beremoved before removing object classes and attributes from the LDAPschema. The following syntax is used to remove LDAP entries:

[0559] dn: dnValue

[0560] changetype: delete

[0561] where dn: dnValue corresponds to the DN of the entry to beremoved.

[0562] The Generated Files are now considered, with reference to FIG.22. The tool (named e.g. ml2config) may be used to map naming andconfiguration data to LDAP, relying on the above described mappingscheme.

[0563] The resulting LDAP information is organized into a set of files.Before initialization, these files are uploaded onto the cluster by thesoftware load tools. The files can then be used by the OMSL SoftwarePlatform to populate the LDAP server running on each cluster duringinitialization.

[0564] Each file defining a platform update (using thecgha:platformUpdate element) is mapped to a plurality of files, definedbelow, where <prefix> is the concatenation of the identifier and theversion of the platform update, separated by a period character (.).Note that <prefix> is shown as “platformUpdate.version” in FIG. 22. Thefiles may be:

[0565] <prefix>.populate.ldif. This file contains:

[0566] The attributes and the object classes, resulting from mapping thenew OMSL types provided in the platform update.

[0567] The entries, resulting from mapping the configuration provided inthe platform update.

[0568] The MIB update levels table.

[0569] <prefix>.apply.ldif. This file defines the current platformupdate version, corresponding to the current software load. This is doneby defining the current platform update table DN in the software loadentries.

[0570] <prefix>.remove.ldif. This file is used to remove from the LDAPserver all the information that does not belong to the current platformupdate.

[0571] <prefix>.rollback.ldif. This file is used to roll back the LDAPserver to its state before applying the <prefix>.apply.ldif file.

[0572] <prefix>.cleanup.ldif. This file is used to remove from the LDAPserver all the entries that have been added by applying the<prefix>.populate.ldif file.

[0573] <prefix>.next.xml. This file gives a brief description of theplatform in order to be able to perform the next platform update.

[0574] The LDIF files can then be loaded onto the LDAP server, dependingon the platform update strategy, as described below.

[0575] The OMSL Software Platform is updated in a controlled manner inorder to apply a new platform update defining a software load and aconfiguration update to the platform.

[0576] First of all, the LDAP server is populated using the<prefix>.populate.ldif described above. The LDAP server can be populatedin advance. The <prefix>.apply.ldif file provides the DN of the currentplatform update table, and hence the platform takes into account the newconfiguration update and software load. One of two possible scenariosthen occurs:

[0577] The platform update is successful: the platform and all itscomponents continue to run correctly. In this case, the OMC (Operation &Management Center) gives the instruction to commit. All the informationthat does not belong to the current platform update must then be removedfrom the LDAP server, using the <prefix>.remove.ldif file.

[0578] The platform update is unsuccessful: one or more components failto run correctly and the OMC gives the instruction to rollback. In thiscase, the <prefix>.rollback.ldif file must be used to return the LDAPserver to its previous state. This file provides the DN of the previousplatform update table, thus enabling the platform to run using theprevious configuration load and software load. Finally, in case ofrollback, it is necessary to clean up the LDAP server, using<prefix>.cleanup.ldif. This removes all the entries that were addedduring population of the LDAP server.

[0579] In both cases, the platform returns to a stable state after theupdate process. In the second case, when the OMC gives the instructionto rollback, the new state of the platform is exactly equivalent to theprevious one.

[0580] Basically, the OMSL-to-LDAP mapping may be applied to the MIBs.By way of example, Exhibit Eh9 shows a mapping of a component typeconfiguration MIB.

[0581] The OMSL code (here, CGHA-ML) for the MIB is shown at Eh9-A. TheMIB defines an object named componentDescriptor , corresponding toversion 1 of a boot server. Assuming this is update level 1 of theconfiguration, the corresponding LDAP (“user”) entry may be as shown atEh9-B. The relative Distinguished Name or RDN iscgha-object-name=componentDescriptor.

[0582] It will be understood that other OMSL entities of the MIBs may bemapped to LDAP, on the basis of the above described mapping schemes. Inthe exemplary embodiment, only the “configuration oriented” OMSLentities are mapped to LDAP. However, other OMSL entities may be mappedto LDAP as well.

[0583] Also, there has been proposed an OMSL language (being bothOperational and Modeling), and a mapping to a directory system language(or DSSL) to represent the current condition of the platform (“currentload”), and, if desired, a possible new condition (“software load”).

[0584] This invention also encompasses a platform, at runtime, havingthe above described LDAP data, however not the OSML data from which suchLDAP data have been mapped. It will also be appreciated that thisincludes the possibility that the DSSL be directly used as anOperational and Modeling Language, at least in part, e.g. for theconfiguration oriented information, as described.

[0585] Accordingly, this aspect of this invention allows one or more ofthe following:

[0586] upgrade modification of the schema defining the configurationstate of the platform;

[0587] downgrade modification of the schema defining the configurationstate;

[0588] upgrade modification of the configuration state of the platform;

[0589] downgrade modification of the configuration state;

[0590] commit of the configuration modification;

[0591] rollback of the configuration modification;

[0592] uniform access to the configuration.

[0593] This invention is of interest in the case of a redundantplatform, as it has appeared from the above description. However, thisshould not be seen as a necessary feature, and the invention may alsoapply to a non redundant platform as well.

[0594] More generally, this invention covers a platform and/or itsparts, whether considered at the level of design, or at runtime. Itfurther covers various corresponding methods, as they may be extractedfrom the above description.

[0595] Thus, there is proposed a method of preparing loadable softwarefor a platform, the method comprising the steps of:

[0596] a. preparing first data (e.g. at the model level of items 2010and 2020 in FIG. 9) defining a given software to be loaded,

[0597] b. generating second data from said first data, said second datacomprising identifiers of software elements to be loaded (e.g. item 2030in FIG. 9), and

[0598] c. generating third data from said second data, and from adefinition of the platform on which the third software load data is tobe loaded (e.g. items 1570, 2400 and/or 2500 in FIG. 10).

[0599] There is also proposed an apparatus for aiding software load in aplatform, said apparatus comprising:

[0600] a package repository,

[0601] a model repository, and

[0602] software load aiding code, interacting with the packagerepository and the model repository, said software load aiding codebeing capable of converting an expression of a software load in a modellanguage into a combination of code and configuration data being validfor execution in the platform.

[0603] The above method and apparatus are subject, optionally, to allthe refinements described herein.

[0604] Independently, the features of a platform in operation areencompassed, as well as the methods involved in its operation. Thisincludes, but is not limited to, the directory server and/or LDAPaspects.

[0605] This invention also covers the software code as used in thisinvention, especially when made available on any appropriatecomputer-readable medium. The expression “computer-readable medium”includes a storage medium such as magnetic or optic, as well as atransmission medium such as a digital or analog signal.

[0606] The software code basically includes, separately or together, thecodes as used when writing the OSML and/or LDAP files (or equivalent),and/or accompanying executable code or macros (or equivalent), e.g. inLDAP, as well as precursors and/or generators of such codes, and as theresulting code, as applicable e.g. in a platform and/or directoryserver. The invention also encompasses the combinations of such codeswith language dependent and/or hardware dependent code and/or data. Theinvention also encompasses an operating system, comprising part or allof such code.

[0607] Exhibit Eh1—Exemplary Document Type Definition (DTD)

[0608] The DTD is as shown in the right column of the following table.The identifying labels in the left column form no part of the DTD. <?xmlversion=“1.0” encoding=“us-ascii” ?> <!--CGHAML DTDident “@(#)cghaml.dtd1.34 01/07/19 SMI”--> A <!--Generic Elements--> A1 <!ELEMENTcgha:description (#PCDATA)> A2 <!ELEMENT cgha:import(cgha:description?)> <!ATTLIST cgha:import href CDATA #REQUIRED> A3<!ELEMENT cgha:package (cgha:description?, cgha:import*,((cgha:interface| cgha:structure| cgha:enumeration|cgha:objectReference| cgha:reference| cgha:exception| cgha:event)*|cgha:component))> <!ATTLIST cgha:package name CDATA #REQUIRED> B<!--Interface Model--> B1 <!ELEMENT cgha:interface (cgha:description?,cgha:inherit?, cgha:constant*, (cgha:attribute| cgha:operation)*,cgha:publish*)> <!ATTLIST cgha:interface type CDATA #REQUIRED versionCDATA #REQUIRED leaf (yes|no) ‘no’ native (yes|no) ‘no’ singleton(yes|no) ‘no’> B2 <!ELEMENT cgha:inherit (cgha:description?)> <!ATTLISTcgha:inherit type CDATA #REQUIRED version CDATA #REQUIRED> B3 <!ELEMENTcgha:constant (cgha:description?)> <!ATTLIST cgha:constant name CDATA#REQUIRED type CDATA #REQUIRED value CDATA #REQUIRED> B4 <!ELEMENTcgha:attribute (cgha description?, cgha:init*)> <!ATTLIST cgha:attributename CDATA #REQUIRED type CDATA #REQUIRED version CDATA #IMPLIED array(yes|no) ‘no’ map (yes|no) ‘no’ mode (R|RW) ‘RW’ configuration (yes|no)‘no’> B5 <!ELEMENT cgha:init (cgha:description?, cgha:init*)> <!ATTLISTcgha:init name CDATA #IMPLIED member CDATA #IMPLIED attribute CDATA#IMPLIED reference CDATA #IMPLIED key CDATA #IMPLIED value CDATA#IMPLIED final (yes|no) ‘no’> B6 <!ELEMENT cgha:operation(cgha:description?, cgha:request?, cgha:reply?, cgha:raise*)> <!ATTLISTcgha:operation name CDATA #REQUIRED mode (rpc|oneway) ‘rpc’> B7<!ELEMENT cgha:request (cgha:description?, cgha:parameter+)> B8<!ELEMENT cgha:reply (cgha:description?, cgha:parameter+)> B9 <!ELEMENTcgha:parameter (cgha:description?)> <!ATTLIST cgha:parameter name CDATA#REQUIRED type CDATA #REQUIRED version CDATA #IMPLIED array (yes|no)‘no’> B10 <!ELEMENT cgha:structure (cgha description?, cgha:member+)><!ATTLIST cgha:structure type CDATA #REQUIRED version CDATA #IMPLIED>B11 <!ELEMENT cgha:member (cgha:description?)> <!ATTLIST cgha:membername CDATA #REQUIRED type CDATA #REQUIRED version CDATA #IMPLIED array(yes|no) ‘no’ map (yes|no) ‘no’> B12 <!ELEMENT cgha:enumeration(cgha:description?, cgha:enumValue+)> <!ATTLIST cgha:enumeration typeCDATA #REQUIRED version CDATA #IMPLIED> B13 <!ELEMENT cgha:enumValue(cgha:description?)> <!ATTLIST cgha:enumValue name CDATA #REQUIRED valueCDATA #IMPLIED> B14 <!ELEMENT cgha: objectReference (cgha:description?)><!ATTLIST cgha:objectReference type CDATA #REQUIRED version CDATA#REQUIRED referencedObjectType CDATA #REQUIRED referencedObjectVersionCDATA #REQUIRED> B15 <!ELEMENT cgha:reference (cgha:description?)><!ATTLIST cgha:reference type CDATA #REQUIRED> B16 <!ELEMENT cgha:raise(cgha:description?)> <!ATTLIST cgha:raise type CDATA #REQUIRED versionCDATA #IMPLIED> B17 <!ELEMENT cgha:exception (cgha:description?,cgha:member*)> <!ATTLIST cgha:exception type CDATA #REQUIRED versionCDATA #IMPLIED> B18 <!ELEMENT cgha:publish (cgha:description?)><!ATTLIST cgha:publish type CDATA #REQUIRED version CDATA #REQUIRED> B19<!ELEMENT cgha:event (cgha:description?, cgha:member*)> <!ATTLISTcgha:event type CDATA #REQUIRED version CDATA #REQUIRED> C <!--ComponentModel--> C1 <!ELEMENT cgha:component (cgha:description?, cgha:use*,cgha:type, cgha:sap*)> <!ATTLIST cgha:component type CDATA #REQUIREDversion CDATA #REQUIRED> C2 <!ELEMENT cgha:use (cgha:description?)><!ATTLIST cgha:use type CDATA #REQUIRED minVersion CDATA #REQUIREDmaxVersion CDATA #REQUIRED> C3 <!ELEMENT cgha:type (cgha:description?,cgha:provide*, cgha:mib)> C4 <!ELEMENT cgha:sap (cgha:description?,cgha:provide*, cgha:mib?)> <!ATTLIST cgha:sap name CDATA #REQUIRED scope(instance|assignment) #REQUIRED access (cluster|management)‘management’> C5 <!ELEMENT cgha:provide (cgha:description?)> <!ATTLISTcgha:provide type CDATA #REQUIRED minVersion CDATA #REQUIRED maxVersionCDATA #REQUIRED> C6 <!ELEMENT cgha:mib (cgha:description?,(cgha:context| cgha:object)*)> C7 <!ELEMENT cgha:context(cgha:description?, (cgha:context| cgha:object)*)> <!ATTLISTcgha:context name CDATA #REQUIRED map (yes|no) ‘no’> C8 <!ELEMENTcgha:object (cgha:description?, (cgha:init*, (cgha:context|cgha:object)*))> <!ATTLIST cgha:object name CDATA #IMPLIED type CDATA#REQUIRED map (yes|no) ‘no’> D <!--Software Load Model--> D1 <!ELEMENTcgha:softwareLoad (cgha:description?, cgha:import*, cgha:cluster,cgha:componentLoad*)> <!ATTLIST cgha:softwareLoad name CDATA #REQUIREDversion CDATA #REQUIRED> D2 <!ELEMENT cgha:cluster (cgha:description?,cgha:provide*, cgha:mib)> <!ATTLIST cgha:cluster version CDATA#REQUIRED> D3 <!ELEMENT cgha:componentLoad (cgha:description?,cgha:init*)> <!ATTLIST cgha:componentLoad type CDATA #REQUIRED versionCDATA #REQUIRED> E <!--Configuration Update Model--> E1 <!ELEMENTcgha:configurationUpdate (cgha:description?, cgha:import*,cgha:softwareLoadDefinition, cgha:clusterConfiguration?,(cgha:typeConfiguration| cgha:instanceConfiguration|cgha:assignmentConfiguration| cgha:removeInstance|cgha:removeAssignment)*)> <!ATTLIST cgha:configurationUpdate name CDATA#REQUIRED version CDATA #REQUIRED> E2 <!ELEMENTcgha:softwareLoadDefinition (cgha:description?)> <!ATTLISTcgha:softwareLoadDefinition name CDATA #REQUIRED version CDATA#REQUIRED> E3 <!ELEMENT cgha:clusterConfiguration (cgha:description?,cgha:init*)> E4 <!ELEMENT cgha:typeConfiguration (cgha:description?,cgha:init*)> <!ATTLIST cgha:typeConfiguration type CDATA #REQUIRED> E5<!ELEMENT cgha:instanceConfiguration (cgha:description?,cgha:sapConfiguration*)> <!ATTLIST cgha:instanceConfiguration name CDATA#REQUIRED type CDATA #REQUIRED> E6 <!ELEMENTcgha:assignmentConfiguration (cgha:description?,cgha:sapConfiguration*)> <!ATTLIST cgha:assignmentConfiguration nameCDATA #REQUIRED type CDATA #REQUIRED> E7 <!ELEMENT cgha:sapConfiguration(cgha:description?, cgha:init*)> <!ATTLIST cgha:sapConfiguration nameCDATA #REQUIRED> E8 <!ELEMENT cgha:removeInstance (cgha:description?)><!ATTLIST cgha:removeInstance name CDATA #REQUIRED> E9 <!ELEMENTcgha:removeAssignment (cgha:description?)> <!ATTLISTcgha:removeAssignment name CDATA #REQUIRED> F <!--Platform UpdateModel--> F1 <!ELEMENT cgha:platformUpdate (cgha:description?,cgha:import*, cgha:currentLoadDefinition?, cgha:softwareLoadDefinition,cgha:configurationUpdateDefinition*)> <!ATTLIST cgha:platformUpdate nameCDATA #REQUIRED version CDATA #REQUIRED configuration (load|update)‘update’> F2 <!ELEMENT cgha:currentLoadDefinition (cgha:description?)><!ATTLIST cgha:currentLoadDefinition version CDATA #REQUIRED> F3<!ELEMENT cgha:configurationUpdateDefinition (cgha:description?)><!ATTLIST cgha:configurationUpdateDefinition name CDATA #REQUIREDversion CDATA #REQUIRED> F4 <!ELEMENT cgha:currentLoad (cgha:import*,cgha:currentCluster, (cgha:currentType | cgha:currentInstance |cgha:currentAssignment)*)> <!ATTLIST cgha:currentLoad version CDATA#REQUIRED platformUpdateName CDATA #REQUIRED platformUpdateVersion CDATA#REQUIRED softwareLoadName CDATA #REQUIRED softwareLoadVersion CDATA#REQUIRED> F5 <!ELEMENT cgha:currentCluster (cgha:provide*, cgha:mib)><!ATTLIST cgha:currentCluster version CDATA #REQUIRED updateLevel CDATA#REQUIRED> F6 <!ELEMENT cgha:currentType (cgha:init*)> <!ATTLISTcgha:currentType type CDATA #REQUIRED version CDATA #REQUIREDupdateLevel CDATA #REQUIRED> F7 <!ELEMENT cgha:currentInstance(cgha:sapConfiguration*)> <!ATTLIST cgha:currentInstance name CDATA#REQUIRED type CDATA #REQUIRED updateLevel CDATA #REQUIRED> F8 <!ELEMENTcgha:currentAssignment (cgha:sapConfiguration*)> <!ATTLISTcgha:currentAssignment name CDATA #REQUIRED type CDATA #REQUIREDupdateLevel CDATA #REQUIRED>

[0609] Exhibit Eh2—Tables Describing Elements of the DTD

[0610] In each table, the upper leftmost cell repeats the label of theelement being described, as it appears in the DTD of Exhibit Eh1. Theupper rightmost cell repeats the name of the element in the DTD. Thenext rows discuss attributes, if any. One or more last rows (singlecolumn) may recite the sub-elements, if any, and may also include notes.A3 cgha:package name Specifies the package identifier. By convention,the name of a package begins with the reversed DNS name of theorganization that created or controls the package. That organization canthen organize the namespace of its packages according to its ownrequirements.

[0611] B1 cgha:interface type Specifies the identifier of the currentlydefined interface. version Specifies the version of the interface, apositive integer. leaf Specifies inheritance. If the leaf attribute isset to “yes”, no other interface may inherit from this one. The defaultvalue of this attribute is “no”. native Specifies whether code isgenerated by compilation of the currently defined interface. If thenative attribute is set to “yes”, no code is generated. The defaultvalue of this attribute is “no”. This mechanism allows the smoothintegration of code, developed with specific semantics, into the globalmodel. singleton Makes it possible to associate a procedural model witheach SAP. A singleton interface can only be accessed by requiring areference to the SAP that contains an instance of it. Therefore, onlyone object per SAP can be an instance of a singleton interface. If thesingleton attribute is set to “yes”, the interface is a singletoninterface. The default value of this attribute is “no”.

[0612] B2 cgha:inherit type Specifies the fully qualified type name ofthe base interface from which the currently specified interfaceinherits. version Specifies the version of the base interface.

[0613] B3 cgha:constant name Specifies the identifier of the constant.type Specifies the type of the constant. This type must be a simpletype. value Specifies the value of the constant. The value must becompatible with the type of the constant.

[0614] B4 cgha:attribute name Specifies the identifier of the interfaceattribute. type Specifies the type of the interface attribute: either asimple type or one of the following types: a structure, an enumeration,a reference, an object reference. For all types which are not simpletypes, the type attribute specifies the fully qualified type name.version Specifies the version of the attribute type (optional). arraySpecifies whether the attribute is an array. If the attribute is set to“yes”, the attribute is an array. The default value of this attribute is“no”. map Specifies whether the attribute is a map. If the map attributeis set to “yes”, the attribute is a map. The default value of thisattribute is “no”. mode Specifies the read/write permissions foraccessing the attribute from the perspective of the interface client.The default permissions are read and write (RW). If the permissions areset to read (R) no write access is provided to the client. configurationSpecifies whether the attribute is configuration information. Thedefault value for the configuration attribute is “no”. Configurationattributes are stored in the Cluster Configuration Repository (LDAP).Configuration attributes must be initialized. The initialization is doneusing cgha:init elements. This initialization can be done at interfacedefinition level, at component definition level, at software loaddefinition level or at configuration update level. The attribute typedefined by the type and version attributes must have been previouslydefined.

[0615] B5 cgha:init name Specifies the identifier of the object beinginitialized. This attribute must be set when initializing a specificobject in the initialization of a MIB. member Specifies the member of astructure being initialized. This attribute must be set wheninitializing a specific member in the initialization of a structure.reference Identifies the referenced object or component. For areferenced object, the reference attribute is set to object. For areferenced component, the reference attribute is set to instance orassignment depending on the scope of the component. This informationenables the value attribute to be interpreted correctly when referenceand object reference type attributes are initialized. attributeSpecifies which attribute is being initialized. This attribute must beset when initializing a specific attribute of an object. key Specifiesthe key of the item being initialized. This must be set wheninitializing a specific item in an array of items or in a map of items.For a map of items, its value can be any string. For an array of items,its value must be an integer value. value Specifies the value of asimple type attribute or member (leaf in the initialization tree). Thevalue must be compatible with the type of the attribute or member. finalControls the initialization semantics

[0616] B6 cgha:operation name Specifies the identifier of the operation.mode Specifies the semantics of the operation. Two modes can bespecified: synchronous operation, specified using rpc, and one-wayoperation, specified using oneway. Synchronous operation means that thecaller of the operation waits for it to complete before proceeding.One-way operation means that the caller of the operation does not waitfor it to complete before proceeding. The default mode is rpc.

[0617] B9 cgha:parameter name Specifies the identifier of the parameter.type Specifies the type of the parameter: simple type, structure type orenumeration type. For structures and enumerations, the type attributespecifies the fully qualified type name of that type. version Specifiesthe version of the parameter type (optional) array Specifies whether theparameter is an array. If the array attribute is set to “yes”, theparameter is an array. The default value of this attribute is “no”.

[0618] B10 cgha:structure type Specifies the identifier of the currentlydefined structure. version Specifies the optional version of thestructure.

[0619] B11 cgha:member name Specifies the identifier of the member. typeSpecifies the type of the member, which can be either a simple type orone of the following types: structure ; enumeration ; object reference ;reference for all types which are not simple types. The type attributeis the fully qualified type name of that type. version Specifies theversion of the member type (optional) array Specifies whether the memberis an array. If the array attribute is set to “yes”, the member is anarray. The default value of this attribute is “no”. map Specifieswhether a member of a structure is a map. If the map attribute is set to“yes”, the member is a map. The default value of this attribute is “no”.Note that the value of the map attribute must be set to “no” for membersof exceptions and events. The type defined by the type and versionattributes must have been previously defined.

[0620] B12 cgha:enumeration type Specifies the identifier of thecurrently defined enumeration. version Specifies the version of theenumeration (optional).

[0621] B13 cgha:enumValue name Specifies the identifier of theenumeration value. In the same enumeration it is not possible to havedifferent enumeration values with the same identifier. value Specifiesthe value of the enumeration value. It must be different from everyother value in the same enumeration. If this attribute is not defined,the value of the enumeration value is generated automatically.

[0622] B14 cgha:objectReference type Specifies the identifier of theobject reference. version Specifies the version of the object reference.referencedObjectType Specifies the fully qualified type name of theobject pointed to by the reference. referencedObjectVersion Specifiesthe version of the referenced object. This attribute must be a positiveinteger.

[0623] B15 cgha:reference type Specifies the identifier of thereference.

[0624] B16 cgha:raise type Specifies the fully qualified type name ofthe exception. If it is a structure or an enumeration, the typeattribute is the fully qualified type name of that type. versionSpecifies the version of the exception (optional).

[0625] B17 cgha:exception type Specifies the identifier of the currentlydefined exception. version Specifies the version of the exception(optional).

[0626] B18 cgha:publish type Specifies the fully qualified type name ofthe event. version Specifies the version of the event.

[0627] B19 cgha:event type Specifies the identifier of the event.version Specifies the version of the event.

[0628] C1 cgha:component type Specifies the identifier of the currentlydefined component. version Specifies the version of the component.

[0629] C2 cgha:use type Specifies the fully qualified type name of theinterface that is used by the component. This type must be an interfacetype. minVersion Specifies the oldest version of the interface that isused (this corresponds to the version with the lowest version number).maxVersion Specifies the most recent version of the interface that isused (this corresponds to the version with the highest or equal to theminVersion attribute.

[0630] C3 cgha:type No attribute C3 cgha:type # configuration is definedby the most recent interface (that is, the interface with the highestversion number).

[0631] C4 cgha:sap name Specifies the identifier of the SAP. scopeSpecifies the scope of the SAP with respect to the HA behavior of thecomponent. The instance scope binds the SAP to the component instancelife cycle. The assignment scope binds the SAP to the componentassignment life cycle. access Specifies if the SAP is visible to the OMCthrough the Management Agent. This attribute can only take one of twovalues: management or cluster. If access is set to management, the SAPis visible to the OMC. If access is set to cluster, the SAP is notvisible to the OMC. In both cases, the SAP is visible within thecluster. # this interface must support all these versions. However, ifmultiple versions of an interface are provided, the configuration isdefined by the most recent interface (the interface with the highestversion number).

[0632] C5 cgha:provide type Specifies the fully qualified type name ofthe interface. This type must be an interface type. minVersion Specifiesthe oldest version of the interface that is used (this corresponds tothe version with the lowest version number). maxVersion Specifies themost recent version of the interface that is used (this corresponds tothe version with the highest version number). This attribute must begreater than or equal to the minVersion attribute.

[0633] C6 cgha:mib No attribute

[0634] C7 cgha:context name Specifies the identifier of the namingcontext. map Specifies whether or not the element defines a map ofcontexts. If the attribute is set to “yes”, the element defines a map ofcontexts. In this case, each context is identified in the map by aunique key. New instances can be created at runtime.

[0635] C8 cgha:object name Specifies the identifier of the object. In aMIB contained in a SAP, it is possible to associate at most one unnamedobject, which is an instance of a singleton interface. An unnamed objecthas no name attribute specified and must appear directly within thecgha:mib element, not within a contained cgha:context. Furthermore, itis not possible to have named objects that are instances of a singletoninterface. In all other cases, the objects must be named. type Specifiesthe fully qualified type name of the interface that the objectimplements. This interface must be provided in the element containingthe MIB. The configuration is defined by the most recent versionprovided, that is the version with the highest version number. mapSpecifies whether the element defines a map of objects. If the mapattribute is set to “yes”, the element defines a map of objects. In thiscase, each object is identified in the map by a unique key. Newinstances can be created at runtime.

[0636] D1 cgha:softwareLoad name Specifies the identifier of thesoftware load. version Specifies the version of the software load. #required for a specific software load. A software load cannot containtwo different versions of the same component type.

[0637] D2 cgha:cluster version Specifies the version of the clusterconfiguration definition. D2 cgha:cluster

[0638] D3 cgha:componentLoad type Specifies the fully qualified typename of the component. version Specifies the version of the component.

[0639] E1 cgha:configurationUpdate name Specifies the identifier of theconfiguration update. version Specifies the version of the configurationupdate.

[0640] E2 cgha:softwareLoadDefinition name Specifies the identifier ofthe software load. version Specifies the version of the software load.

[0641] E3 cgha:clusterConfiguration No attribute

[0642] E4 cgha:typeConfiguration type Specifies the fully qualified typename of the component that is initialized. This component type must bepart of the associated software load.

[0643] E5 cgha:instanceConfiguration name Specifies the identifier ofthe instance. type Specifies the fully qualified type name of thecomponent that is initialized. This component type must be part of theassociated software load. It is not necessary to specify the version ofthe component, because it is not possible to have multiple versions ofthe same component in a software load.

[0644] E6 cgha:assignmentConfiguration name Specifies the identifier ofthe assignment. type Specifies the fully qualified type name of thecomponent that is initialized. This component type must be part of theassociated software load.

[0645] E7 cgha:sapConfiguration name Specifies the identifier of the SAPthat is initialized.

[0646] E8 cgha:removeInstance name Specifies the identifier of theinstance to be removed.

[0647] E9 cgha:removeAssignment name Specifies the identifier of theassignment to be removed.

[0648] F1 cgha:platformUpdate name Specifies the identifier of theplatform update. version Specifies the version of the platform update.configuration Specifies whether the platform update configuration iscompletely new configuration (the configuration attribute is set toload) or an update of the existing configuration (the configurationattribute is set to update).

[0649] F2 cgha:currentLoadDefinition version Specifies the version ofthe current load.

[0650] F3 cgha:configurationUpdateDefinition name Specifies theidentifier of the configuration update. version Specifies the version ofthe configuration update.

[0651] F4 cgha:currentLoad version Specifies the version of the currentload. platformUpdateName Specifies the identifier of the currentplatform update. platformUpdateVersion Specifies the version of thecurrent platform update. softwareLoadName Specifies the identifier ofthe current software load. softwareLoadVersion Specifies the version ofthe current software load.

[0652] F5 cgha:currentCluster version Specifies the version of thecluster configuration definition. updateLevel Specifies the update levelof the cluster configuration. # MIB is the most recent version of theinterface that is provided, that is the version with the highest versionnumber.

[0653] F6 cgha:currentType type Specifies the fully qualified type nameof the component. Each component type specified must have beenpreviously defined and imported. version Specifies the version of thecomponent. updateLevel Specifies the update level of the componentconfiguration.

[0654] F7 cgha:currentInstance name Specifies the identifier of theinstance. type Specifies the filly qualified type name of the componenttype associated with the instance. updateLevel Specifies the updatelevel of the instance configuration.

[0655] F8 cgha:currentAssignment name Specifies the identifier of theassignment. type Specifies the fully qualified type name of thecomponent type associated with the assignment. updateLevel Specifies theupdate level of the assignment configuration.

[0656] TABLE Eh2-1 Identif. ELEMENT versionMin versionMax C2 cgha:useRequ. Requ. C5 cgha:provide Requ. Requ.

[0657] TABLE Eh2-2 Identif. ELEMENT Version UpdateLevel B1cgha:interface Required B2 cgha:inherit Required B4 cgha:attributeOptional B9 cgha:parameter Optional B10 cgha:structure Optional B11cgha:member Optional B12 cgha:enumeration Optional B14cgha:objectReference Required B16 cgha:raise Optional B17 cgha:exceptionOptional B18 cgha:publish Required B19 cgha:event Required C1cgha:component Required D1 cgha:softwareLoad Required D2 cgha:clusterRequired D3 cgha:componentLoad Required E1 cgha:configurationUpdateRequired E2 cgha:softwareLoadDefinition Required F1 cgha:platformUpdateRequired Required F2 cgha:currentLoadDefinition Required Required F3cgha:configurationUpdateDefinition Required Required F4 cgha:currentLoadRequired Required F5 cgha:currentCluster Required Required F6cgha:currentType Required Required F7 cgha:currentInstance — Required F8cgha:currentAssignment — Required

[0658] Exhibit Eh3—Description of CGHA-ML

[0659] CGHA-ML is an example of an XML-based operational modelinglanguage.

[0660] Eh3.0—XML

[0661] Generally, the XML syntax is defined in the XML specificationavailable from W3C at http://www.w3.org/TR. The basic markup principleof XML is as follows:

[0662] consider the character string “TITLE” (hereinafter termed anidentifier),

[0663] in an corresponding XML document, what is between “<TITLE>” and“</TITLE>” is an “element”,

[0664] other data may be used to define what an element like “<TITLE>”may contain (including other nested elements, also called“sub-elements”), what attributes it may have. These other data may bseparate, i.e. contained in a Document Type Definition (DTD), or haveother formats, e.g. the one known as “XML schemas”.

[0665] In XML, a DTD follows the same markup principle as XML itself,however with slightly different syntax rules, and reserved words like#PCDATA. The DTD expressions are enclosed between “<!XXXXX” and “>”,where “XXXXX” is a DTD keyword, e.g. “ELEMENT”, and the rest is a name,followed with one or more other arguments or “sub-elements”. Theexpressions are case-sensitive. The DTD provides a formal definition ofthe elements with <!ELEMENT . . . >. Each ELEMENT may also haveattributes, defined with the syntax <!ATTLIST . . . >). This defines therelationship among the data elements. An <!ENTITY# . . . > clause may beused to build a parameter entity for internal use in the DTD. Finally,comments are enclosed between “<!--” and “-->” markups.

[0666] Thus, the syntax of all elements of an OMSL may be defined in aDTD, a detailed example of which appears in Exhibit Eh1.

[0667] The main features of the exemplary DTD of will now be commented.

[0668] The labels added in the left column for each identifier ofExhibit Eh1 are used in this description and in the tables of ExhibitEh2.

[0669] It will be appreciated that, in a DTD, many elements areinterrelated, and may not be commented in all occurrences.

[0670] Eh3.1—Generic Constructs

[0671] The exemplary document type definition or DTD has genericconstructs, used in common to all models.

[0672] Elements are characterized by an identifier. An identifier is astring of characters, which should be formed in accordance with specificrules (including naming rules). The identifiers of the DTD will now beconsidered in more detail.

[0673] At A1, the DTD has a cgha:description element, which may be usedto provide a plain text description of the element in which it islocated. Many elements in the DTD may have an optional description usingcgha:description a sub-element. This will not be further commented.

[0674] An OMSL may be organized in independent documents, implemented asfiles in an underlying file system.

[0675] At label B5, the DTD has a cgha:init element which may be used tospecify the initial values of attributes. The cgha:init element may alsocontain an optional list of other cgha:init elements; the list ofinitialization elements may be used to navigate into the contents of a“plural” entity, for example to initialize the members of a structure.

[0676] The usage of cgha:init, i.e. the initialization, may be done atmultiple levels: interface definition level, component definition level,software load definition level, configuration update definition level.By default (final attribute set to “no”), it is possible to lateroverwrite the initialization. Setting final to yes at a given level inthe sequence of processing: interface definition level/componentdefinition level/software load definition level/configuration updatedefinition level will prohibit later overwriting. Such a scheme builds ahierarchy of initializations. For example, a default value might beassigned to an attribute in the definition of the interface. This valuemight be overwritten in the definition of the component providing theinterface, and this value might finally be updated in the configuration.If the final attribute is set to “yes”, the value cannot be overwrittenthereafter.

[0677] An OMSL may provide defined types, which may be organized inpackages, e.g. simple types and also new types. Simple types may includeall or part of the usual “system” types of software entities, e.g.Boolean, Byte, Short, Int, Long, Float, Double, String, UnsignedByte,UnsignedShort, UnsignedInt, UnsignedLong.

[0678] These simple types may further be used in plural types, here:

[0679] structure (B10), having members (B11);

[0680] enumeration (B12), having values called enum Values (B13).

[0681] Interface, used to specify services and managed objects providedby a component; e.g. cgha:interface

[0682] object reference, used to define references to objects, e.g.cgha:objectReference

[0683] Reference, used to define references to component instances orassignments, e.g. cgha:reference

[0684] Exception, used to specify exceptions that can be raised duringinvocations of operations, e.g. cgha:exception

[0685] Event, used to specify events in the OMSL, that are published bythe software (platform and applications) running on the network element,e.g. cgha:event

[0686] Component, used to specify a component that is deployed on theplatform, e.g. cgha:component

[0687] Each defined type is characterized by its type identifier and bythe sub-elements it contains. The type identifier is defined by the typeattribute of the element, and may be formed in accordance with specificnaming rules. The exemplary DTD supports a single namespace for definedtypes. Thus, parsers may be used to check that type identifiers areunique within a software load model, that is, that no type definitionoverwrites another type definition.

[0688] When it is necessary to refer to a type from within anotherpackage, a fully qualified type name may be used, e.g. in the form of aconcatenation of the package identifier and the type identifier.

[0689] The types may contain nested sub-elements, e.g. as defined in theexemplary DTD, while distinguishing whether these are optional, orrequired.

[0690] Types of an OMSL may be defined in a package e.g. by means of thecgha:package element, which appears at A3 in the DTD. Thus, a givencgha:package is related to its own set of type definitions. In theexemplary CGHA-ML, the set comprises the following type definitions:cgha:interface, cgha:structure, cgha:objectReference, cgha:reference,cgha:enumeration, cgha:exception, cgha:event, cgha:component.

[0691] Each cgha:package maybe specified as an independent file that maynot contain anything other than that cgha:package element. The samepackage may be defined in more than one cgha:package element. Thepackage is made up of all the types defined in all the cgha:packageelements with that package name. Every type in a given package must havea different name (identifier) from every other type in the package.

[0692] Eh3.2—Interface Model

[0693] The interface model of the OMSL will now be described, with theexemplary syntax and semantics of each element which may be used in it.

[0694] The cgha:interface element (at B1 in the DTD) may be used tospecify the functionality provided by a component and to define thetypes of the objects that are instantiated in MIBs (ManagementInformation Bases).

[0695] An OMSL may allow interfaces to be specialized, usinginheritance, in order to add functionality. The cgha:inherit element(B2) may be used to designate a base interface, if any, that thecurrently specified interface (then called the derived interface)inherits from. The ancestors of a derived interface are its baseinterface and the ancestors of that base interface. Only singleinheritance is supported in the exemplary embodiment.

[0696] The cgha:constant element (B3) is used to define constants in thescope of an interface.

[0697] The cgha:attribute element (B4) defines the attributes that arepart of an interface. An attribute is a field of the interface thatholds data values. In the exemplary embodiment, versioning is supportedat the interface definition level. It may be supported at the attributedefinition level as well.

[0698] The cgha:operation element (B6) defines the operations that arepart of an interface specification. Several possibilities exist:

[0699] in the example, a oneway operation should not contain a replydescription. It is also possible to define a oneway operation thatcontains no request parameters.

[0700] it is possible to define an rpc operation that contains replyparameters without having request parameters. It is also possible todefine an rpc operation that contains no request parameters and no replyparameters.

[0701] exceptions can be triggered in order to provide out-of-band errorsupport.

[0702] The cgha:request element (B7) defines the request part of anoperation. It may contain a list of one or more parameters(cgha:parameter; B9). This list, when defined, specifies the parametersassociated with the request.

[0703] The cgha:reply element (B8) defines the reply part of anoperation. It contains a list of one or more parameters (cgha:parameter;B9), which specifies the parameters associated with the reply.

[0704] The cgha:structure element (B10) is used to define structures.The cgha:member element (B11) may be used to specify the members ofstructures, events and exceptions.

[0705] The cgha:enumeration element (B12) is used to specify anenumeration type. It may contain a list of enumeration values, whichspecifies the possible values of the enumeration. Each member of thelist may be specified using the cgha:enumValue element (B13). In theexample, the values associated with an enumeration are of type Int.

[0706] The cgha:objectReference element (B14) is used to definereferences to objects. In the example:

[0707] the data related to a cgha:objectReference element may beinitialized by means of the cgha:init element, with the referenceattribute of the cgha:init element being set to object.

[0708] an object reference may be used as a type of a configurationattribute, only when configuration is set to “yes”. Thus, thecgha:objectReference element only supports references to objects thatare in the same MIB as that containing the cgha:objectReference elementitself.

[0709] The cgha:reference element (B15) is used to define simplereferences to component instances or assignments. (In the examples, thereferences are dot-separated names; however, LDAP-like references may beused as well.

[0710] In the example:

[0711] data related to a cgha:reference element maybe initialized usingthe cgha:init element.

[0712] if the referenced component is an instance, the referenceattribute of the cgha:init element may be set to instance.

[0713] if the referenced component is an assignment, the referenceattribute of the cgha:init element is set to assignment.

[0714] a reference may be used as a type of a configuration attributeonly when configuration is set to “yes”.

[0715] For both the objectReference and the reference, dot-separatednames are used in the example; however, other notations may be used aswell, e.g. LDAP-like references.

[0716] The cgha:raise element (B16) should be used to specify theexceptions that might be raised during the invocation of an operation.The cgha:exception element (B17) is used to define an exception that canbe generated during the invocation of an operation.

[0717] The cgha:publish element (B18) is used to specify the events thatmight be published by objects implementing the currently definedinterface.

[0718] The cgha:event element (B19) may be used to specify the eventsthat are handled by the network element software using the eventmechanism of the underlying Software Platform. For members of events,the value of the map attribute should be set to “no”.

[0719] Eh3.3—Component Model

[0720] The Component model of the OMSL will now be described, with theexemplary syntax and semantics of each element which may be used in it.

[0721] The cgha:component element (C1 in the DTD) may be used to definea component type. This definition may include the interfaces that areprovided or used by the component, the events that are published by thecomponent and the MIBs of the component.

[0722] The component type configuration is initialized to the propervalues and partially finalized in order to avoid later overwriting. Inthe example, up to four SAPs (Service Access Points) may be defined inthe component:

[0723] an instanceManagement SAP providing access to component instancemanagement.

[0724] an assignmentManagement SAP providing access to componentassignment management.

[0725] a log SAP providing log services.

[0726] a control SAP providing control of the log manager.

[0727] The cgha:use element (C2) may be used to declare the versions ofan interface that are used by a component. The cgha:type element (C3)may be used to define a component type configuration. The cgha:sapelement (C4) may be used to define a service access point (SAP) in acomponent. The cgha:provide element (C5) may be used to declare theversions of an interface that are provided through a SAP.

[0728] The cgha:mib element (C6) defines a hierarchical naming treedescribing the containment hierarchy of objects. It consists of a numberof objects associated with the leaves and nexus of the naming tree. Thecgha:mib element is used to define the MIB associated with itscontainer. In the example, the cgha:mib element should always becontained within one of the following elements: cgha:sap, cgha:type,cgha:cluster

[0729] In the example, the name space provided by the MIB is local toits container (a SAP if the MIB is associated with a SAP, a componenttype if the MIB is associated with a component type, a cluster if theMIB is associated with the cluster). This means that the MIB itself doesnot need to be identified, and therefore does not have a name attribute.Each object is uniquely defined in a MIB by its full name, whichdescribes the location of the object in the name space of the MIB. Inother words, the MIB may provide the root of the naming context.

[0730] The cgha:context element (C7) issued to define a new namingcontext in the MIB. The period character (.) may be used as theseparator to concatenate names of the naming context tree into a singlefull name inside a MIB. In a given naming context, two different items(context or object) should not have the same identifier.

[0731] The cgha:object element (C8) is used to declare an object insidea specific naming context of a MIB. Each object instantiates an alreadydefined interface. The period character (.) is used as the separator toconcatenate the full name of the naming context and the name of theobject in order to obtain the full name of the object inside the MIB.

[0732] Eh3.4—Software Load Model

[0733] The Software Load model of the OMSL will now be described, withthe exemplary syntax and semantics of each element which may be used init.

[0734] The cgha:softwareLoad element (D1) is used to specify a softwareload. In the exemplary embodiment, each cgha:softwareLoad element shouldbe specified in an independent file.

[0735] The cgha:cluster element (D2) may be used to define the clusterconfiguration MIB.

[0736] The cgha:componentLoad element (D3) may be used to identify thecomponents that are part of the software load. It supportsinitialization of configuration attributes of objects contained in thecomponent type configuration MIB. This initialization may be used, forexample, to select the OS (e.g. Solaris) packages that are required fora specific software load. The parser of the OMSL should ensure theconsistency between the initialization clauses and the MIB.

[0737] Eh3.5—Configuration Update Model

[0738] The cgha:configurationUpdate element (E1) is used to specify aconfiguration update. Each such element should be specified in anindependent file.

[0739] When creating an instance or an assignment, the instanceconfiguration or the assignment configuration should be used. Theinstance or assignment is referred to in the cluster configuration MB.

[0740] The cgha:softwareLoadDefinition element (E2) may be used tospecify the software load configured in the configuration update orplatform update.

[0741] The cgha:clusterConfiguration element (E3) may be used toinitialize configuration attributes of objects contained in the clusterconfiguration MIB. The parser should ensure the consistency between theinitialization clauses and the MIB.

[0742] The cgha:typeConfiguration element (E4) may be used to initializeconfiguration attributes of objects contained in the component typeconfiguration MIB. The parser should ensure the consistency between theinitialization clauses and the MIB.

[0743] The cgha:instanceConfiguration element (E5) maybe used toconfigure an instance of a component.

[0744] The cgha:assignmentConfiguration element (E6) may be used toconfigure an assignment. In an assignment configuration, it is onlypossible to configure SAPs that have an assignment scope.

[0745] The cgha:sapConfiguration element (E7) may be used to initializeconfiguration attributes in the MIB associated with the SAP. The parsershould ensure the consistency between the initialization clauses and theMIB.

[0746] The cgha:removeInstance element (E8) may be used to remove aninstance that has been created previously. The cgha:removeAssignmentelement (E9) may be used to remove an assignment that has been createdpreviously.

[0747] Eh3.6—Platform Update Model

[0748] The cgha:platformUpdate element (F1) may be used to specify aplatform update. Each such element must be specified in an independentfile. The software load defined in each configuration update should bethe same as that defined in the platform update.

[0749] The OMSL parser may check that all attributes with aconfiguration attribute set to “yes” are initialized. The granularity ofthe configuration update may be the MIB. This means that if a MIB iscreated or modified, all the configuration attributes of that MIB mustbe initialized in one or more cgha:configurationUpdate elements. Asindicated, a MIB can be created or modified, using theinstanceConfiguration, assignmentConfiguration, type-Configuration orclusterConfiguration elements.

[0750] Therefore in the case of an update of an existing configuration(configuration attribute set to update), all the configurationattributes of all the MIBs that have been updated must be initialized.

[0751] In the case of a completely new configuration (configurationattribute set to load), all the configuration attributes of all the MIBsthat are defined in the software load should be initialized. These MIBsare the instance MIBs, the assignment MIBs, the component typeconfiguration MIBs, and the cluster configuration MIB.

[0752] The cgha:currentLoadDefinition element (F2) may be used tospecify the current load that is used in the platform update.

[0753] The cgha:configurationUpdateDefinition element (F3) may be usedto specify the configuration update that is used in the platform update.

[0754] The elements labelled F4, F5, F6, F7, F8 are be generated by theSoftware Factory toolchain for its own use:

[0755] The cgha:currentLoad element (F4) may be used to specify in anindependent file the current load of a Network Element: component types,component instances, component assignments, and the cluster definition.

[0756] The cgha:currentCluster element (F5) maybe used to specify theversion and the update level of cluster configuration.

[0757] The cgha:currentType element (F6) may be used to configure thecomponent type configuration MIB.

[0758] The cgha:currentInstance element (F7) may be used to specify eachinstance of a current load. The cgha:currentInstance

[0759] The cgha:currentAssignment element (F8) maybe used to specifyeach assignment of a current load.

[0760] Exhibit Eh4—Exemplary CGHA-ML Code Eh4-1 - attributes of theComponentDescriptor interface <cgha:package name=“com.sun.cgha.types”><cgha:interface type=“ComponentDescriptor” version=“1”> <cgha:attributename=“componentCategory” type=“com.sun.cgha.types.ComponentCategory”mode=“R” configuration=“yes” /> <cgha:attributename=“availabilityDescriptor”type=“com.sun.cgha.types.AvailabilityDescriptor” mode=“R”configuration=“yes” /> <cgha:attribute name=“packagingDescriptor”type=“com.sun.cgha.types.PackagingDescriptor” array=“yes” mode=“R”configuration=“yes” /> </cgha:interface> </cgha:package> Eh4-2:<cgha:enumeration type=“ComponentCategory”> <cgha:enumValue name=“PROXY”value=“0” /> <cgha:enumValue name=“PROXIED” value=“1” /> <cgha:enumValuename=“STANDALONE” value=“2” /> </cgha:enumeration> Eh4-3<cgha:enumeration type=“RedundancyModel”> <cgha:enumValuename=“HOT_RESTART” value=“0” /> <cgha:enumValue name=“NON_HA” value=“1”/> <cgha:enumValue name=“HA_2N” value=“2” /> <cgha:enumValuename=“HA_N_PLUS_1” value=“3” /> </cgha:enumeration> Eh4-4<cgha:structure type=“AvailabilityDescriptor”> <cgha:membername=“redundancyModel” type=“com.sun.cgha.types.RedundancyModel” /><cgha:member name=“restartable” type=“Boolean” /> <cgha:membername=“switchOverEscalationCount” type=“Int” /> <cgha:membername=“switchOverEscalationTimeWindow” type=“Int” /> <cgha:membername=“crimRequestResponseTimeOut” type=“Int” /> </cgha:structure> Eh4-5<cgha:structure type=“CreationDescriptor”> <cgha:member name=“timeOut”type=“Int” /> <cgha:member name=“binaryPath” type=“String” /><cgha:member name=“terminationTimeOut” type=“Int” /> <cgha:membername=“userId” type=“Long” /> <cgha:member name=“groupId” type=“Long” />Eh4-6 <cgha:enumeration type=“PackageType”> <cgha:enumValuename=“DOCUMENTATION” value=“0” /> <cgha:enumValue name=“DEVELOPMENT”value=“1” /> <cgha:enumValue name=“RUNTIME” value=“2” /></cgha:enumeration> <cgha:structure type=“PackagingDescriptor”><cgha:member name=“platform” type=“String” /> <cgha:member name=“os”type=“String” /> <cgha:member name=“type”type=“com.sun.cgha.types.PackageType” /> <cgha:membername=“packageNames” type=“String” array=“yes” /> </cgha:structure><cgha:structure type=“DeploymentDescriptor”> <cgha:membername=“platform” type=“String” /> <cgha:member name=“os” type=“String” /></cgha:structure> Eh4-10 <cgha:package name=“com.sun.cgha.types”xmlns:cgha=“http://www.sun.com/CGHA”> <cgha:importhref=“/com/sun/cgha/types/ComponentDescriptor.1.xml” /> <cgha:interfacetype=“SoftwareComponentDescriptor” version=“1”> <cgha:inherittype=“com.sun.cgha.types.ComponentDescriptor” version=“1” /><cgha:attribute name=“creationDescriptor”type=“com.sun.cgha.types.CreationDescriptor” mode=“R”configuration=“yes”> <cgha:init member=“userId” value=“0” /> <cgha:initmember=“groupId” value=“0” /> </cgha:attribute> <cgha:attributename=“deploymentDescriptor”type=“com.sun.cgha.types.DeploymentDescriptor” array=“yes” mode=“R”configuration=“yes” /> </cgha:interface> </cgha:package> Eh4-11<cgha:package name=“com.sun.cgha.types”xmlns:cgha=“http://www.sun.com/CGHA”> <cgha:importhref=“/com/sun/cgha/types/ComponentDescriptor.1.xml” /> <cgha:interfacetype=“HardwareComponentDescriptor” version=“1”> <cgha:inherittype=“com.sun.cgha.types.ComponentDescriptor” version=“1” /></cgha:interface> </cgha:package> Eh4-20 Eh4-20-A <!--Component typedescription--> <cgha:importhref=“/com/sun/cgha/types/SoftwareComponentDescriptor.1.xml” /><cgha:component type=“SoftwareComponentExample” version=“1”><cgha:description> ... </cgha:description> <cgha:type> <cgha:providetype=“com.sun.cgha.types.SoftwareComponentDescriptor” minVersion=“1”maxVersion=“1” /> ... Eh4-20-B <cgha:mib> <cgha:objectname=“componentDescriptor”type=“com.sun.cgha.types.SoftwareComponentDescriptor”> ...(initialization) Eh4-20-C <cgha:init attribute=“componentCategory”value=“STANDALONE” final=“yes” /> ... Eh4-20-D <cgha:initattribute=“availabilityDescriptor” final=“yes”> <cgha:initmember=“redundancyModel” value=“HA_2N” /> <cgha:initmember=“restartable” value=“FALSE” /> <cgha:initmember=“switchOverEscalationCount” value=“0” /> <cgha:initmember=“switchOverEscalationTimeWindow” value=“1” /> <cgha:initmember=“crimRequestResponseTimeOut” value=“1” /> </cgha:init> ...Eh4-20-E <cgha:init attribute=“creationDescriptor” final=“yes”><cgha:init member=“timeOut” value=“1” /> <cgha:init member=“binaryPath”value=“...” /> <cgha:init member=“terminationTimeOut” value=“1” /><cgha:init member=“userId” value=“106573” /> <cgha:init member=“groupId”value=“55” /> </cgha:init> ... Eh4-20-F <cgha:initattribute=“packagingDescriptor”> <cgha:init key=“0”> <cgha:initmember=“platform” value=“common” /> <cgha:init member=“os”value=“common” /> <cgha:init member=“type” value=“RUNTIME” /> <cgha:initmember=“packageNames”> <cgha:init key=“0” value=“PKGCOM1” /></cgha:init> </cgha:init> <cgha:init key=“1”> <cgha:initmember=“platform” value=“SPARC” /> <cgha:init member=“os”value=“Solaris” /> <cgha:init member=“type” value=“RUNTIME” /><cgha:init member=“packageNames”> <cgha:init key=“0” value=“PKGSOL1” /><cgha:init key=“1” value=“PKGSOL2” /> </cgha:init> </cgha:init><cgha:init key=“2”> <cgha:init member=“platform” value=“SPARC” /><cgha:init member=“os” value=“ChorusOS” /> <cgha:init member=“type”value=“RUNTIME” /> <cgha:init member=“packageNames”> <cgha:init key=“0”value=“PKGCHO1” /> <cgha:init key=“1” value=“PKGCHO2” /> </cgha:init></cgha:init> </cgha:init> ... Eh4-21 - How to Use the instanceManagementSAP <cgha:sap name=“instanceManagement” scope=“instance”><cgha:description> This SAP gives access to the mandatory MIB that mustbe associated with each component instance. </cgha:description><cgha:provide type=“com.sun.cgha.types.management.Instance”minVersion=“1” maxVersion=“1” /> <cgha:mib> <cgha:objecttype=“com.sun.cgha.types.management.Instance”> </cgha:object></cgha:mib> </cgha:sap> </cgha:component> </cgha:package> Eh4-30<cgha:package name=“com.sun.cgha.types.management”xmlns:cgha=“http://www.sun.com/CGHA”> ... <cgha:enumerationtype=“UsageState”> <cgha:enumValue name=“IDLE” value=“0” /><cgha:enumValue name=“ACTIVE” value=“1” /> <cgha:enumValue name=“BUSY”value=“2” /> </cgha:enumeration> <cgha:interface type=“Assignment”version=“1” singleton=“yes”> <cgha:attribute name=“usage”type=“com.sun.cgha.types.management.UsageState” mode=“R” /></cgha:interface> ... </cgha:package> Eh4-31 - How to use theassignmentManagement SAP <!--Generic management types--> <cgha:importhref=“/com/sun/cgha/types/management/ Assignment.1.xml” /><cgha:component type=“SoftwareComponentExample” version=“1”> ...<cgha:sap name=“assignmentManagement” scope=“assignment”><cgha:description> This SAP provides access to the MO associated withassignments. </cgha:description> ... <cgha:providetype=“com.sun.cgha.types.management.Assignment” minVersion=“1”maxVersion=“1” /> <cgha:mib> <cgha:objecttype=“com.sun.cgha.types.Assignment”> <cgha:description> The usage stateof a component. </cgha:description> </cgha:object> </cgha:mib></cgha:sap> ... </cgha:component>

[0761] Exhibit Eh5—Tables Related to the MIBs and SAPs TABLE Eh5-1 TheComponent Type Configuration MIB Mandatory object namecomponentDescriptor Related object typecom.sun.cgha.types.ComponentSoftwareDescriptor orcom.sun.cgha.types.ComponentHardwareDescriptor Both of these typesinherit from: com.sun.cgha.types.ComponentDescriptor Attributes (andtype) com.sun.cgha.types.ComponentDescriptor: * componentCategory (enumtype). * availabilityDescriptor (structure). * packagingDescriptor(array of structures). com.sun.cgha.types.SoftwareComponentDescriptor: *creationDescriptor (structure). * deploymentDescriptor (array ofstructures). com.sun.cgha.types.HardwareComponentDescriptor: * Nospecific attributes found.

[0762] TABLE Eh5-2 The instanceManagement SAP and its MIB Mandatoryobject name (None: singleton interface) Related object typecom.sun.cgha.types.management.Instance Attributes (and type) (optional)Corresponding mandatory instanceManagement SAP

[0763] TABLE Eh5-3 The assignmentManagement SAP and its MIB Mandatoryobject name (None: singleton interface) Related object typecom.sun.cgha.types.management.Assignment Attributes (and type) usage(enum type). This is runtime information exposed to remote clients.Corresponding assignmentManagement mandatory SAP

[0764] TABLE Eh5-4 Attributes of the ComponentDescriptor Interface TypeAttribute Description componentCategory Provides configuration typeinformation required by the CRIM. availabilityDescriptor Providesavailability information required by the CRIM: The redundancy model ofthe component. The switch-over escalation count and time window. Thetime out for a component to respond to a CRIM request. Definition ofwhether the component is restartable or not. packagingDescriptorProvides packaging description required by the SLBT (via the m12swloadtool).

[0765] Exhibit Eh6—Mapping from CGHA-ML—Exemplary Tables TABLE Eh6-1Mapping CGHA-ML Name Tokens to Java MBeans CGHA-ML CGHA-ML ConstructIdentifier Mapping to Java MBeans Package thispackagecom.sun.thispackage Type ThisClass ThisClass Operation thisMethodthisMethod (Generated ThisClass.ThisMethodReply return type) Attributewith thisAttribute getThisAttribute read access Attribute withthisAttribute setThisAttribute write access Constant THIS_CONSTANTTHIS_CONSTANT Enumeration value ENUM_VALUE ENUM_VALUE

[0766] TABLE Eh6-2 Mapping CGHA-ML Name Tokens to RPC and C CGHA-MLCGHA-ML Construct Identifier Mapping to RPC and C Package thispackage(not mapped) Type ThisClass this_class (prefix) Operation thisMethodthis_class_this_method (Generated this_class_this_method_reply returntype) Attribute with thisAttribute this_class_get_this_attribute readaccess Attribute with thisAttribute this_class_set_this_attribute writeaccess Constant THIS_CONSTANT THIS_CONSTANT Enumeration ENUM_VALUEENUM_VALUE value

[0767] TABLE Eh6-3 Mapping CGHA-ML Name Tokens to LDAP CGHA-ML CGHA-MLConstruct Identifier Mapping to LDAP Package thispackagecom-sun-thispackage Type ThisClass com-sun-this-package-ThisClassAttribute thisAttr com-sun-this-package-ThisClass- n-thisAttr (*)

[0768] Exhibit Eh7 Eb7-0 - LDAP layout software load <-- software loaddefinition  version   dn platform update <-- platform update definition version   table cluster <-- cluster configuration  version   updatelevel    mib types  component type <-- component type configuration  version    update level     mib ... instances  component instance <--component instance configuration   sap    version     update level     mib ... ... assignments  component assignment <-- componentassignment configuration   sap    version     update level      mib ...... Eh7-O - LDAP object classes Eh7-O1 (cgha-attribute--oc) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-attribute-name-oid NAME ‘cgha-attribute-name’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-attribute--oc-oid NAME ‘cgha-attribute--oc’ SUP top MUST (cgha-attribute-name ) ) Eh7-O2 (cgha-member--oc) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-member-name-oid NAME ‘cgha-member-name’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) dn: cn=schema changetype:modify add: objectclasses objectclasses: ( cgha-member--oc--oid NAME‘cgha-member--oc’ SUP top MUST ( cgha-member-name ) ) Eh7-O3(cgha-element--oc) dn: cn=schema changetype: modify add: attributetypesattributetypes: ( cgha-key-oid NAME ‘cgha-key’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) dn: cn=schema changetype:modify add: objectclasses objectclasses: ( cgha-element--oc-oid NAME‘cgha-element--oc’ SUP top MUST ( cgha-key ) ) Eh7-O4(cgha-structure--oc) dn: cn=schema changetype: modify add:attributetypes attributetypes: ( cgha-structure-type-oid NAME‘cgha-structure-type’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 StringSINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypesattributetypes: ( cgha-structure-version-oid NAME‘cgha-structure-version’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5String SINGLE-VALUE ) dn: cn=schema changetype: modify add:objectclasses objectclasses: ( cgha-structure--oc-oid NAME‘cgha-structure--oc’ SUP top MUST ( cgha-structure-type ) MAY (cgha-structure-version ) ) Eh7-O5 (cgha-object-reference--oc) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-object-reference-type-oid NAME ‘cgha-object-reference-type’ SYNTAX1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-object-reference-version-oid NAME ‘cgha-object-reference-version’SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-object-reference-mib-dn-oid NAME ‘cgha-object-reference-mib-dn’SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-object-reference-full-name-oid NAME‘cgha-object-reference-full-name’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 #IA5 String SINGLE-VALUE) dn: cn=schema changetype: modify add:objectclasses objectclasses: ( cgha-object-reference--oc-oid NAME‘cgha-object-reference--oc’ SUP top MUST ( cgha-object-reference-type $cgha-cgha-object-reference-version $ cgha-cgha-object-reference-mib-dn $cgha-cgha-object-reference-full-name ) ) Eh7-O6 (cgha-reference--oc) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-reference-type-oid NAME ‘cgha-reference-type’ SYNTAX1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-reference-dn-oid NAME ‘cgha-reference-dn’ SYNTAX1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn: cn=schemachangetype: modify add: objectclasses objectclasses: (cgha-reference--oc-oid NAME ‘cgha-reference--oc’ SUP top MUST (cgha-reference-type $ cgha-reference-dn ) ) Eh7-O7 (cgha-object--oc) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-object-name-oid NAME ‘cgha-object-name’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-object--oc-oid NAME ‘cgha-object--oc’ SUP top MUST (cgha-object-name ) ) Eh7-O8 (cgha-interface--oc) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-interface-type-oid NAME ‘cgha-interface-type’ SYNTAX1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-interface-version-oid NAME ‘cgha-interface-version’ SYNTAX1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn: cn=schemachangetype: modify add: objectclasses objectclasses: (cgha-interface--oc-oid NAME ‘cgha-interface--oc’ SUP top MUST (cgha-interface-type $ cgha-interface-version ) ) Eh7-O9(cgha-context--oc) dn: cn=schema changetype: modify add: attributetypesattributetypes: ( cgha-context-name-oid NAME ‘cgha-context-name’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-context--oc-oid NAME ‘cgha-context--oc’ SUP top MUST (cgha-context-name ) ) Eh7-O10 (cgha-cluster-version--oc) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-cluster-version-oid NAME ‘cgha-cluster-version’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-cluster-version--oc-oid NAME ‘cgha-cluster-version--oc’ SUP topMUST ( cgha-cluster-version ) ) Eh7-O11 (cgha-cluster-update-level--oc)dn: cn=schema changetype: modify add: attributetypes attributetypes: (cgha-cluster-update-level-oid NAME ‘cgha-cluster-update-level’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-cluster-update-level--oc-oid NAME ‘cgha-cluster-update-level--oc’SUP top MUST ( cgha-cluster-update-level ) ) Eh7-O12(cgha-component-type--oc) dn: cn=schema changetype: modify add:attributetypes attributetypes: ( cgha-component-type-oid NAME‘cgha-component-type’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # DirectoryString SINGLE-VALUE ) dn: cn=schema changetype: modify add:objectclasses objectclasses: ( cgha-component-type--oc-oid NAME‘cgha-component-type--oc’ SUP top MUST ( cgha-component-type ) ) Eh7-O13(component-type-version--oc) dn: cn=schema changetype: modify add:attributetypes attributetypes: ( cgha-component-type-version-oid NAME‘cgha-component-type-version’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 #Directory String SINGLE-VALUE ) dn: cn=schema changetype: modify add:objectclasses objectclasses: ( cgha-component-type-version--oc-oid NAME‘cgha-component-type-version--oc’ SUP top MUST (cgha-component-type-version ) ) Eh7-O14(cgha-component-type-update-level--oc) dn: cn=schema changetype: modifyadd: attributetypes attributetypes: (cgha-component-type-update-level-oid NAME‘cgha-component-type-update-level’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15# Directory String SINGLE-VALUE ) dn: cn=schema changetype: modify add:objectclasses objectclasses: ( cgha-component-type-update-level--oc-oidNAME ‘cgha-component-type-update-level--oc’ SUP top MUST (cgha-component-type-update-level ) ) Eh7-O15(cgha-component-instance-name--oc) dn: cn=schema changetype: modify add:attributetypes attributetypes: ( cgha-component-instance-name-oid NAME‘cgha-component-instance-name’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 #Directory String SINGLE-VALUE ) dn: cn=schema changetype: modify add:objectclasses objectclasses: ( cgha-component-instance-name--oc-oid NAME‘cgha-component-instance-name--oc’ SUP top MUST (cgha-component-instance-name $ cgha-component-type ) ) Eh7-O16(cgha-component-instance-update-level--oc) dn: cn=schema changetype:modify add: attributetypes attributetypes: (cgha-component-instance-update-level-oid NAME‘cgha-component-instance-update-level’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-component-instance-update-level--oc-oid NAME‘cgha-component-instance-update-level--oc’ SUP top MUST (cgha-component-instance-update-level ) ) Eh7-O17(cgha-component-assignment-name--oc) dn: cn=schema changetype: modifyadd: attributetypes attributetypes: ( cgha-component-assignment-name-oidNAME ‘cgha-component-assignment-name’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-component-assignment-name--oc-oid NAME‘cgha-component-assignment-name--oc’ SUP top MUST (cgha-component-assignment-name $ cgha-component-type ) )Eh7-O18(cgha-component-assignment-update-level--oc) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-component-assignment-update-level-oid NAME‘cgha-component-assignment-update-level’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-component-assignment-update-level--oc-oid NAME‘cgha-component-assignment-update-level--oc’ SUP top MUST (cgha-component-assignment-update-level ) ) Eh7-O19 (cgha-sap-name--oc)dn: cn=schema changetype: modify add: attributetypes attributetypes: (cgha-sap-name-oid NAME ‘cgha-sap-name’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-sap-access-oid NAME ‘cgha-sap-access’ SYNTAX1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE ) dn:cn=schema changetype: modify add: objectclasses objectclasses: (cgha-sap-name--oc-oid NAME ‘cgha-sap-name--oc’ SUP' top MUST (cgha-sap-name $ cgha-sap-access ) )Eh7-O20(cgha-platform-update-version--oc) dn: cn=schema changetype:modify add: attributetypes attributetypes: (cgha-platform-update-version-oid NAME ‘cgha-platform-update-version’SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String SINGLE-VALUE)dn: cn=schema changetype: modify add: objectclasses objectclasses: (cgha-platform-update-version--oc-oid NAME‘cgha-platform-update-version--oc’ SUP top MUST (cgha-platform-update-version ) ) Eh7-O21 (cgha-update-level--oc) dn:cn=schema changetype: modify add: attributetypes attributetypes: (cgha-update-level-oid NAME ‘cgha-update-level’ SYNTAX1.3.6.1.4.1.1466.115.121.1.12 # DN SINGLE-VALUE ) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-updated-oid NAME ‘cgha-updated’ SYNTAX1.3.6.1.4.1.1466.115.121.1.26 # IA5 String SINGLE-VALUE ) dn: cn=schemachangetype: modify add: attributetypes attributetypes: (cgha-update-level-dn-oid NAME ‘cgha-update-level-dn’ SYNTAX1.3.6.1.4.1.1466.115.121.1.12 # DN SINGLE-VALUE ) dn: cn=schemachangetype: modify add: objectclasses objectclasses: (cgha-update-level--oc-oid NAME ‘cgha-update-level--oc’ SUP top MUST (cgha-update-level $ cgha-update-level-dn $ cgha-updated ) )Eh7-O22(cgha-software-load-version--oc) dn: cn=schema changetype: modifyadd: attributetypes attributetypes: ( cgha-software-load-version-oidNAME ‘cgha-software-load-version’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15SINGLE-VALUE ) dn: cn=schema changetype: modify add: attributetypesattributetypes: ( cgha-platform-update-dn-oid NAME‘cgha-platform-update-dn’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 # DNSINGLE-VALUE ) dn: cn=schema changetype: modify add: objectclassesobjectclasses: ( cgha-software-load-version--oc-oid NAME‘cgha-software-load-version--oc’ SUP top MUST (cgha-software-load-version $ cgha-platform-update-dn ) )

[0769] Exhibit Eh8—Tables Related to LDAP Mapping TABLE Eh8-T0 LDAPSyntax LDAP Code Definition IA5 String 1.3.6.1.4.1.1466.115.121.1.26values are case sensitive Directory String 1.3.6.1.4.1.1466.115.121.1.15values are not case sensitive Distinguished Name1.3.6.1.4.1.1466.115.121.1.12 values are DNs

[0770] TABLE Eh8-T11 OMSL Attribute types LDAP 1 Simple LDAP attribute 2Simple (array) LDAP attribute designating an object class array itemssub-entries instantiating the object class 3 Enum LDAP attributedesignating an object class + instance(s) of that object class 4Structure See table Eh8-T12

[0771] TABLE Eh8-T12 OMSL LDAP 1 cgha:interface LDAP object class (namedalong id-mapping rules) attributes see table Eh8-T11 2 cgha:membersimple LDAP attribute others see table Eh8-T11 3 cgha:structure LDAPobject class (named along id-mapping rules) structure members seecgha:member 4 cgha:objectReference LDAP object class (named alongid-mapping rules) 5 cgha:reference LDAP object class (named alongid-mapping rules)

[0772] Exhibit Eh9 Eh9 - A <cgha:packagename=“com.sun.cgha.container.bootServer”> <cgha:componenttype=“BootServer” version=“1”> <cgha:type> <cgha:mib> <cgha:objectname=“componentDescriptor”type=“com.sun.cgha.types.SoftwareComponentDescriptor”> <cgha:init .../>... </cgha:object> </cgha:mib> </cgha:type> </cgha:component></cgha:package> Eh9 - B dn: cgha-object-name=componentDescriptor,cgha-component-type-update-level=1, cgha-component-type-version=1,cgha-component-type=com.sun.cgha.container.bootServer.BootServer,ou=types,o=cgha_root

What is claimed is:
 1. A computer system comprising: a plurality ofcomponents; a plurality of interfaces enabling interactions between saidplurality of components; a repository of data representing a currentcondition of said plurality of components and an interaction betweensaid plurality of components, wherein at least some of said dataincludes a historic indication being at least one of a version and anupdate level; and a search code enabling said repository of data to besearched for determining a status of a particular one of said pluralityof components.
 2. The computer system according to claim 1, wherein saidrepository of data is arranged as a tree structure.
 3. The computersystem according to claim 2, further comprising a table enablingcorrespondence between a non-historic identifier of a particular one ofsaid plurality of components and a portion of said repository of saiddata corresponding to said particular one of said components identifiedby a historic identifier.
 4. The computer system according to claim 3,wherein said historic indication comprises an identifier in said treestructure.
 5. The computer system according to claim 1, wherein saidsearch code is arranged as a directory server cooperating with saidrepository.
 6. The computer system according to claim 1, wherein saidrepository of data comprises separate subsets of data for modeling saidcondition of said plurality of components and said interactions of saidplurality of components.
 7. The computer system according to claim 1,wherein said repository of data comprises data modeling softwarecomponents and data modeling hardware components.
 8. The computer systemaccording to claim 1, wherein said repository of data comprises a firstsubset of data defining a directional interaction between a servercomponent providing and interface and a client component using saidinterface.
 9. The computer system according to claim 8, wherein saidfirst subset of data is arranged to attach a “provide” version rangeidentifying value to said server component and a “use” version rangeidentifying value to said client component.
 10. The computer systemaccording to claim 1, wherein said repository of data includes a currentgroup of data and is adapted to received a new group of data; andfurther comprising an update code capable of concurrently processingsaid current group of data and said new group of data, with a view toupdate said computer system.
 11. The computer system according to claim10, wherein said update code is capable of commit from said currentgroup of data to said new group of data; and said update code is capableof rollback from said new group of data to said current group of data.12. The computer system according to claim 1, wherein said repository ofdata comprises data relating to a configuration state of said computersystem.
 13. The computer system according to claim 1, wherein saidrepository of data relating to a schema of a configuration state of saidcomputer system.
 14. The computer system according to claim 1, whereinsaid search code is accessible to a management service code.
 15. Amethod of managing a computer system, comprising: defining a pluralityof entities in said computer system as a plurality of components and aplurality of interactions between said plurality of components; andstoring a group of data forming a searchable representation of saidplurality of components and said plurality of interactions.
 16. Themethod according to claim 15, wherein said searchable representation isarranged as a tree structure.
 17. The method according to claim 15,further comprising maintaining a table enabling correspondence between anon-historic identifier of a particular one of said plurality ofcomponents and said group of data for said particular one of saidplurality of components, wherein said group of data comprises a historicindication.
 18. The method according to claim 17, wherein said historicidentifier comprises part of a designation of a corresponding portion ofsaid group of data in said tree structure.
 19. The method according toclaim 15, wherein said group of data comprises a first subset formodeling said plurality of components and a second subset for modelingsaid plurality of interactions.
 20. The method according to claim 15,wherein said group of data comprises data for modeling softwarecomponents and data for modeling hardware components.
 21. The methodaccording to claim 15, wherein said group of data comprises datadefining a plurality of direction interactions, wherein each directioninteraction is between a server component providing an interface and aclient component utilizing said interface.
 22. The method according toclaim 21, wherein said data defining a plurality of directioninteractions comprises data arranged to attach a “provide” version rangeidentifying value to said server component and a “use” version rangeidentifying value to said client component.
 23. The method according toclaim 21, further comprising: wherein said group of data comprises acurrent group of data and is adapted to received a new group of data;and concurrently processing said current group of data and said newgroup of data, with a view to update said computer system.
 24. Themethod according to claim 23, wherein concurrently processing saidcurrent group of data and said new group of data comprises: committingfrom said current group of data to said new group of data, when anupdate is authorized; and rolling back from said new group of data tosaid current group of data, when said update is not authorized.
 25. Themethod according to claim 15, wherein said group of data comprises datarelating to a configuration state of said computer system.
 26. Themethod according to claim 15, wherein said group of data relating to aschema of a configuration state of said computer system.
 27. The methodaccording to claim 15, further comprising determining a status of aparticular one of said plurality of components.
 28. The method accordingto claim 27, wherein said determining said status is accessible to amanagement service.
 29. The method according to claim 15, wherein saidgroup of data comprises data referred to component instances and datareferred to component assignments.
 30. A computer-readable mediumcontaining a plurality of instructions which when executed cause acomputer device to implement a method of managing a computer system,comprising: generating a plurality of data defining a plurality ofcomponents and a plurality of interactions between said plurality ofcomponents; storing said plurality of data as a searchable treestructure; searching said tree structure wherein a status of aparticular component is determined; and enabling an interaction betweena first and second ones of said plurality of components as a function ofsaid status.
 31. The computer-readable medium according to claim 30,further comprising maintaining a table defining a mapping between anon-historic identifier of each of said plurality of components and aportion of said plurality of data corresponding to each of saidplurality of components identified by a historic indication, whereinsaid historic indication is associated with a particular leaf of saidsearchable tree structure.
 32. The computer-readable medium according toclaim 30, wherein said plurality of data comprises: a first subset ofdata for modeling said components; and a second subset of data formodeling said interactions between said plurality of components.
 33. Thecomputer-readable medium according to claim 32, wherein said pluralityof data comprises: a third subset of data for modeling softwarecomponents of said plurality of components; and a fourth subset of datafor modeling hardware components of said plurality of components. 34.The computer-readable medium according to claim 30, further comprising:updating a portion of said plurality of data if a configuration updateis authorized; and rolling back an updated portion of said plurality ofdata if a configuration update is not authorized.